From: 


tbr 


To: 


Sent: 


Subject: 


Saturday, October 01, 1994 12:55 AM 
'lisar* 

forwarded message from Bill Zuravleff 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Return-Path: <billz@ghidra> 

Received: from ghidra.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA14890; Fri, 30 Sep 94 22:52:12 PDT 
Received: from localhost by ghidra.microunityxom (8.6.4/muse-sw.2) 

id WAA19655; Fri, 30 Sep 1994 22:50:54 -0700 
Message-Id: <1 994 1 0010550. WAA 1 9655@ghidra.microunity .com> 
X-Mailer: ELM [version 2.3 PL1 1] 
From: billz@ghidra (Bill Zuravleff) 

To: tbr@ghidra (Tim B. Robinson), mws@ghidra (Mark Semmelmeyer), 
woody@ghidra (Jay Tomlinson), dickson@ghidra (Richard Dickson), 
agc@ghidra (Alan Corry) 

Subject: Can't releasebom in verilog/bsrc 

Date: Fri, 30 Sep 94 22:50:54 BST 

In (repeatedly re) trying to releasebom ~ not commit — 
in bsrc I get the following message: 

Problems with cvs commit (1) - aborting 

Output from 'cvs commit -n -m "releasebom: File needs to be up-to-da...' 
cvs commit: sticky tag M 3 1 .0' for file 'BOM' is not a branch 
cvs [commit aborted]: correct above errors first! 
Unable to release /s2/euterpe/verilog/bsrc/BOM 

*NOTE* Log message saved in file /tmp/releasebom.msg.18857 


And a note that it was releasing and unchanged bom in 
every subdirectory. 

If you can get me past this problem, please let me know. 

Thanks, 

billz 

End of forwarded message 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Saturday, October 01, 1994 1:14 AM 
To: 'Bill Zuravleff 

Cc: 'Alan Cony'; 'Richard Dickson'; 'Mark Semmelmeyer'; Tim B. Robinson'; 'Jay Tomlinson' 
Subject: bsrc BOM 133.0 


Bill Zuravleff wrote (on Fri Sep 30): 

OK, BOM 133.0 is released. 

I did get these previously unseen messages: ??? 


This is okay. All it means is that you haven't released the very 
latest stuff in xlu. 


Lisa R. 


Releasing BOM in /s2/euterpe/verilog/bsrc/xlu 

mkbom: NOTE: File "c2.srf ' is found in the repository but is not being included in this BOM. 
mkbom: NOTE: File "cl.srf ' is found in the repository but is not being included in this BOM. 
mkbom: NOTE: File "zs3.srf" is found in the repository but is not being included in this BOM. 
mkbom: NOTE: File M cs3.srf' is found in the repository but is not being included in this BOM. 
mkbom: NOTE: File "xbus.srf * is found in the repository but is not being included in this BOM, 
mkbom: NOTE: File "cs2.srf ' is found in the repository but is not being included in this BOM. 
mkbom: Note: File "db_7a.srf ' has version 23. 1 and the repository has version 23.2. 
mkbom: 

mkbom: Note: File "dc_8a.srf ' has version 21.4 and the repository has version 21.5. 
mkbom: 

mkbom: Note: File "misc2.srf" has version 22,3 and the repository has version 22.4. 
mkbom: 

mkbom: Note: File "misc3.srf" has version 22.2 and the repository has version 22.3. 
mkbom: 

mkbom: Note: File "cL Q a_7.srf ' has version 21 .3 and the repository has version 21.4. 
mkbom: 

mkbom: Note: File "route.pl" has version 19.8 and the repository has version 19.9. 

Regards, 
billz 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Saturday, October 01, 1994 12:57 PM 
To: , agc@ambiorix'; , tbr@ambiorix l 
Cc: 'hopper@ambiorix' 
Subject: top-level status 


Hi, 

Well, I got paged most of the evening and this morning and I grabbed 
all blocks that ran except nb. I noticed that Alan started up nb 
again so I'll take that when it's done. 

I am a bit worried about the io blocks. I ran another top-level yesterday 
evening ( things run pretty smoothly now) and I noticed a couple 
of row in io have grown way beyond the original boundary. Did io use 
some pla structures that did not meet timing and therefore use large 
or gates now ???? 

I'll start up another top-level right now and work on the data-path placements. 
If anybody is available to look at io , that would be help. I'll copy 
the dff and pi f file of the top-level in 

~geert/chip/euterpe/verilog/bsrc/gards.tmp 

This top-level placement is a bit messed up but it allows you to look at 
the io section and find the larger gates. 


Geert 


Exhibit C7 


Page 3 of 703 


From: tbr 

Sent: Saturday, October 01 , 1 994 1 :07 PM 

To: 'Geert Rosseel' 

Cc: 'agc@ambiorix'; 'hopper@ambiorix , 

Subject: top-level status 

Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Sat Oct 1): 


Hi, 

Well, I got paged most of the evening and this morning and I grabbed 
all blocks that ran except nb. I noticed that Alan started up nb 
again so I'll take that when it's done. 

I am a bit worried about the io blocks. I ran another top-level yesterday 
evening ( things run pretty smoothly now) and I noticed a couple 
of row in io have grown way beyond the original boundary. Did io use 
some pla structures that did not meet timing and therefore use large 
or gates now ???? 

Everything used to meet timing. Have they been remade since the 
timing numbers were added. It's probably just that they got made 
whilt topt wes thinking 24s ad 32s gates were free. 

I'll start up another top-level right now and work on the data-path placements. 
If anybody is available to look at io , that would be help. I'll copy 
the dff and pif file of the top-level in 

I can look at it. 


~geert/chip/euterpe/verilog/bsrc/gards.tmp 

This top-level placement is a bit messed up but it allows you to look at 
the io section and find the larger gates. 


Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, October 01, 1994 1:07 PM 
'Geert Rosseel' 

, agc@ambiorix'; , hopper@ambiorix' 
top-level status 


Geert Rosseel wrote (on Sat Oct 1) : 


Hi, 


Well 7 I got paged most of the evening and this morning and I grabbed 
all blocks that ran except nb. I noticed that Alan started up nb 
again so I'll take that when it's done. 

I am a bit worried about the io blocks. I ran another top-level yesterday 
evening ( things run pretty smoothly now) and I noticed a couple 
of row in io have grown way beyond the original boundary. Did io use 
some pla structures that did not meet timing and therefore use large 
or gates now ???? 

Everything used to meet timing. Have they been remade since the timing numbers were 
added. It's probably just that they got made whilt topt wes thinking 24s ad 32s gates 
were free . 

I'll start up another top-level right now and work on the data-path placements. 
If anybody is available to look at io , that would be help. I'll copy 
the dff and pif file of the top-level in 

I can look at it . 


-geert /chip/euterpe/verilog/bsrc/gards . tmp 

This top-level placement is a bit messed up but it allows you to look at 
the io section and find the larger gates . 


Geert 
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From: Geert Rosseel [geert@rhea] 

Sent: Saturday, October 01 , 1 994 1 :22 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert: 

pageme gmake geert_euterpegards start : Oct__01_ll : 07 end: Oct_01_ll : 20 exit 
1 
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To: 


Sent: 


From: 


vant [vanthof@hestia] 

Saturday, October 01, 1994 1:42 PM 

Tim B. Robinson' 


Cc: 'Dave Van't Hof ; 'Mark Hofmann' 
Subject: dracula machines free 


tim, 

I don't know who you might want to tell this too, but the dracula machines 
cyclops and tomato are now free. 1 don't have any plans for them over 
the weekend as I can't run any fullchip euterpe lvs runs until the xbcol 
cells are fixed and Tom figures out what is missing in the layout. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 


Thanks, 
Dave 
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From: vant [vanthof@hestia] 

Sent: Saturday, October 01 , 1 994 1 :43 PM 

To: 'Geert Rosseel' 

Cc: 'Dave Van't Hof; 'Mark Hofmann'; Tim B. Robinson'; 'Lisa Robinson'; Tom Vo' 

Subject: probes finished 


Geert, 

the vdd and vss probes for euterpe finished. The vss file is 1.2GB and the vdd file is 
800MB. I'll have to write a special c program to split them into smaller files for 
plotting. 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMOl (tm) All kids love Log! # inc luce 

<std_disclaim ,h> 


Exhibit C7 


Page 8 of 703 


Subject: 


Cc: 


Sent: 


To: 


From: 


tbr 

Saturday, October 01, 1994 1:53 PM 
'vant' 

•Mark Hofmann'; 'Dave Van't Hof 
dracula machines free 


Follow Up Flag: Follow up 
Flag Status: Red 

vant wrote (on Sat Oct 1): 
tim, 

I don't know who you might want to tell this too, but the dracula machines 
cyclops and tomato are now free. I don't have any plans for them over 
the weekend as I can't run any fullchip euterpe Ivs runs until the xbcol 
cells are fixed and Tom figures out what is missing in the layout. 


Thanks. 


HI send something to hardheads. That should get to all the likley 
suspects! 


Tim 
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From: 


tbr 


To: 


Cc: 


Sent: 


Subject: 


Saturday, October 01, 1994 2:04 PM 

'geeif 

'wampler' 

rg routing 


Follow Up Flag: Follow up 
Flag Status: Red 

I have beem looking at the XLU to bypass path a bit more and I'm 
pretty sure we can make timing OK. However, I have noticed that in rg, the 
router has used m2 for some of the long runs from the rgcr section to 
the main block. Surprisingly, even with over 800fF as a result, we 
still make timing (though you will be seeing rgcr powered way up). 
Oddly, this seems to be affecting only one bit (45), and in the final 
route it manage to get it on M4 again so we have one giant cell 
sticking out for no reason. 

Given that these nets pass mainly through open spac, I suspect som 
target problem or bad congestion in area of the bypass mux. This 
would not be surprising, but I think we have to figure out how to 
ensure all this stuff is in linesearch M3/M4. 

Kurt, can you take another look at the latest version 
(/u/chip/euterpe/verilog/bsrc/rg/gards/rg-iter). As before it took > 
12hrs to iterate because of the slow routes. Here's the topt report 
for one of the bad paths: 

Original Path state: 

rgcr/UrcValuLRR/u45 (xbffdhl2s 12S) Oport: q_ad0ph IntDel: 100.80 net: RGrcValuRR<45> swg: dh delay: 
747.36ps RC delay: 115. 83ps Ids: 1 pcap: 20.98ff cap: 839.88tT(ext) 

rgl/UopcMx45RR/uO (xbmux5dhl6s 16S) Iport: D0_AD0PH Oport: q_ad0ph IntDel: 105.60 net: 
RGopcMxRR<45> swg: dh delay: 32.85ps RC delay: 1.97ps Ids: 2 pcap: 19.36ff cap: 69.96ff (ext) 

rgh/Uopc45R0/u0 (xbmuxfOdh24s 24S) Iport: D1_AD0PH IntDel: 269.30 

Time through Path: 1255.91 

Path After Optimization using cycle time of 895.00: 

rgcr/XJrcValuLRR/u45 (xbffbdh24s 24S) Oport: q_ad0ph IntDel: 93.80 net: RGrcValuRR<45> swg: dh 
delay: 324.92ps (force) RC delay: 1 15.83ps Ids: 1 pcap: 20.98ff cap: 839.88ff (ext) m21en: 2729.00 m31en: 2.00 
m41en: 0.00 

rgl/UopcMx45RR/u0 (xbmux5dhl 6s 16S) Iport: D0_ADOPH Oport: q_ad0ph IntDel: 105.60 net: 
RGopcMxRR<45> swg: dh delay: 32.85ps RC delay: 1.97ps Ids: 2 pcap: 19.36ff cap: 69.96ff (ext) m21en: 0.00 
m31en: 192.00 m41en: 314.00 

rgh/Uopc45R0/u0 (xbmuxff2dh24s 24S) Iport: D1_AD0PH IntDel: 269.30 

Time through Path: 826.47 

It's the first leg of this path that has the problem, though as I said 
in the final route it did get it in M4. 


Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Saturday, October 01 , 1 994 2:04 PM 

To: , geert@aphrodite' 

Cc: 'wampler@aphrodite' 

Subject: rg routing 


I have beem looking at the XLU to bypass path a bit more and I'm pretty sure we can make 
timing OK. However, I have noticed that in rg, the router has used m2 for some of the 
long runs from the rgcr section to the main block. Surprisingly, even with over 800fF as 
a result, we still make timing (though you will be seeing rgcr powered way up) . 
Oddly, this seems to be affecting only one bit (45) , and in the final route it manage to 
get it on M4 again so we have one giant cell sticking out for no reason. 

Given that these nets pass mainly through open spac, I suspect som target problem or bad 
congestion in area of the bypass mux. This would not be surprising, but I think we have 
to figure out how to ensure all this stuff is in linesearch M3/M4. 

Kurt, can you take another look at the latest version 

(/u/chip/euterpe/verilog/bsrc/rg/gards/rg-iter) . As before it took > 12hrs to iterate 
because of the slow routes. Here's the topt report for one of the bad paths: 

Original Path state: 

rgcr/UrcValuLRR/u4 5 (xbffdhl2s 12S) Oport : cr_adOph 

10 0.80 net: RGrcValuRR<45> swg: dh delay: 747.36ps 

Ids: 1 pcap: 20.98ff cap: 839.88ff (ext) 

rgl/UopcMx4 5RR/u0 (xbmux5dhl6s 16S) Iport : DO_AD0PH 
Oport: q_ad0ph IntDel : 105.60 net: RGopcMxRR<45> swg 
32.85ps RC delay: 1 . 97ps Ids: 2 pcap: 19.36ff cap 

rgh/Uopc4 5R0/u0 (xbmuxf f 2dh2 4s 24S) Iport: D1_AD0PH 

269.30 

Time through Path: 1255.91 

Path After Optimization using cycle time of 895.00: 

rgcr/UrcValuLRR/u4 5 (xbffbdh24s 24S) Oport: q_ad0ph 

IntDel: 93.80 net: RGrcValuRR<4 5> swg: dh delay: 324.92ps (force) RC 

delay: 115.83ps Ids: 1 pcap : 20.98ff cap: 839.88ff (ext) m21en: 

2729.00 m3len: 2.00 m4len: 0.00 

rgl/UopcMx4 5RR/uO (xbmux5dhl6s 16S) Iport: D0_AD0PH 
Oport: q_ad0ph IntDel: 105.60 net: RGopcMxRR<45> swg: dh delay: 

32.85ps RC delay: 1.97ps Ids: 2 pcap: 19.36ff cap: 69.96ff (ext) 

m21en: 0.00 m31en: 192.00 m41en: 314.00 

rgh/Uopc45RO/uO (xbmuxf f 2dh24s 24S) Iport: D1_AD0PH 

IntDel: 269.30 

Time through Path: 8 2 6.47 

It's the first leg of this path that has the problem, though as I said in the final route 
it did get it in M4 . 

Tim 


IntDel: 

RC delay: 115.83ps 


dh delay: 
69.96ff (ext) 
IntDel : 
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From: tbr 

Sent: Saturday, October 01, 1994 2:47 PM 

To: 'woody'; 'billz' 

Cc: 'geert' 

Subject: at port mismatch 

Follow Up Flag: Follow up 

Flag Status: Red 


There is some sort of port mismatch at the top level involving at 
(BOM 133.0). I can't get v2e to compile: 

Reading configuration file tbr.config.tmp .... 
Processing configuration file .... 
Translating Verilog source .... 

(?V2E) ***ERROR*** Erroneous results may occur for port connects on port number "54" of instance "at" of module "at" 
0 warnings 1 errors 

make: *** [gards/tbr_euterpe,v2ej Error 1 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, October 01, 1994 2:47 PM 
'woody@aphrodite'; 'billz@aphrodite' 
'geert@aphrodite' 
at port mismatch 


There is some sort of port mismatch at the top level involving at (BOM 133.0). I can't 
get v2e to compile : 

Reading configuration file tbr . conf ig. tmp .... 
Processing configuration file .... 
Translating Verilog source .... 

(?V2E) ***ERROR*** Erroneous results may occur for port connects on port number "54" of 
instance "at" of module "at" 
0 warnings 1 errors 

make: *** [gards/tbr_euterpe . v2e] Error 1 
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From: Geert Rosseel [geert@rhea] 

Sent: Saturday, October 01, 1994 5:39 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert : 

pageme gmake geert_euterpegards start :Oct_01_13 : 16 end: Oct_01 15:37 exit 
1 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Alan Corry [agc@aphrodite] 
Saturday, October 01, 1994 6:00 PM 
'Geert Rosseel' 

'agc@ambiorix'; 'tbr@ambiorix'; 'hoppe^ambiorix' 
Re: top-level status 


> 


> 


> Hi, 


> 


> Well, I got paged most of the evening and this morning and I grabbed 

> all blocks that ran except rib. I noticed that Alan started up nb again 

> so I'll take that when it * s done . 


I noticed this finished and managed to get to the iter step before stopping with HARD 
errors . One thing that needs to be looked into is the atom count now that we have the 
larger OR gates. Prior to this change the old atom count was 40,000. Its now up to 42000 
and still it fails timing. The prior run had 1 hard error that had failed by 0.5ps, and 
I'd moved a few cells to reduce that particular net. So I'm not sure whther we're 
optimally using the 24s/32s OR gates yet. 

> I am a bit worried about the io blocks. I ran another top-level 
yesterday 

> evening ( things run pretty smoothly now) and I noticed a couple of 

> row in io have grown way beyond the original boundary. Did io use some 

> pla structures that did not meet timing and therefore use large or 

> gates now ???? 

I believe that IO used to meet timing. 


> I'll start up another top-level right now and work on the data-path 
placements . 

> If anybody is available to look at io , that would be help. I'll copy 

> the dff and pif file of the top-level in 
> 

> -geert/chip/euterpe/verilog/bsrc/gards . tmp 
> 

> This top-level placement is a bit messed up but it allows you to look 
at 

> the io section and find the larger gates . 


> Geert 


> 


> 
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From: Geert Rosseel [geert@rhea] 

Sent: Saturday, October 01 , 1 994 7:20 PM 

To: 'geert@rhea' 

Subject: pager log, sender copy 


page from geert to geert: 

pageme gmake geert_euterpegards start :Oct_01_16 : 00 end: Oct_01_17:19 exit 
1 
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From: Jay Tomlinson [woody @demeter] 
Sent: Saturday, October 01 , 1994 9:1 1 PM 
To: Tim B. Robinson' 
Cc: 'billz@aphrodite'; 'geert@aphrodite' 
Subject: at port mismatch, page 

I think this is due to the fact that I checked-in but did not release AT, 

because I had a lot of changes and wanted to be protected by the database. When 

I tried to check in euterpe.V, I found out it had been updated (billz change) so 

I updated and re-started my test (which passed). It looks like now someone has 

released AT (probably for placement reasons). But now I need to get Billz BOM 

before I can release. To work around get the previous AT BOM. 

I won't have much time to work on this, but 1 will get Billz BOM and re-run my 

test to make sure it still works. 

Jay 

Tim B. Robinson wrote (on Sat Oct 1): 

There is some sort of port mismatch at the top level involving at 
(BOM 133.0). I can't get v2e to compile: 

Reading configuration file tbr.config.tmp .... 
Processing configuration file .... 
Translating Verilog source .... 

(?V2E) ***ERROR*** Erroneous results may occur for port connects on port number "54" of instance "at" of module "at" 
0 warnings 1 errors 

make: *** [gards/tbr_euterpe.v2e] Error 1 
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Sent: 
To: 


Cc: 


Subject: 
Follow Up Flag: 
Flag Status: 


From: 


tbr 

Saturday, October 01, 1994 9:16 PM 
'Jay Tomlinson' 

'billz^aphrodite'; 'lisar'; 'geert@aphrodite' 
at port mismatch, page 
Follow up 
Red 


Jay Tomlinson wrote (on Sat Oct 1 ): 

I think this is due to the fact that I checked- in but did not release AT, 
because I had a lot of changes and wanted to be protected by the database. When 
I tried to check in euterpe.V, I found out it had been updated (billz change) so 
I updated and re-started my test (which passed). It looks like now someone has 
released AT (probably for placement reasons). But now I need to get Billz BOM 
before I can release. To work around get the previous AT BOM. 
I won't have much time to work on this, but I will get Billz BOM and re-run my 
test to make sure it still works. 

Great if that fixes it, lisar says she can pick up that BOM for AT and 
then release a new top level BOM to back out that change. 


Tim 
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From: Lisa Robinson [lisar@rhodan] 
Sent: Saturday, October 01 , 1994 9:23 PM 
To: 'Tim B. Robinson' 

Cc: 'billz@aphrodite'; 'geert@aphrodite'; 'Jay Tomiinson' 
Subject: at port mismatch, page 


Tim B. Robinson wrote (on Sat Oct 1): 


Jay Tomiinson wrote (on Sat Oct 1): 

I think this is due to the fact that I checked-in but did not release AT, 
because I had a lot of changes and wanted to be protected by the database. When 
I tried to check in euterpe. V, I found out it had been updated (billz change) so 
I updated and re-started my test (which passed). It looks like now someone has 
released AT (probably for placement reasons). But now I need to get Billz BOM 
before I can release. To work around get the previous AT BOM. 
I won't have much time to work on this, but I will get Billz BOM and re-run my 
test to make sure it still works. 

Great if that fixes it, lisar says she can pick up that BOM for AT and 
then release a new top level BOM to back out that change. 

Tim 


Okay, I've picked up at 5.0 and am compiling now. If it runs I'll 
release. 

Thanks 
Lisa R. 
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From: Jay Tomlinson [woody @demeter] 
Sent: Saturday, October 01 , 1994 9:38 PM 
To: 'Lisa Robinson' 

Cc: 'billz^aphrodite'; 'geert@aphrodite'; Tim B. Robinson' 
Subject: at port mismatch, page 

I have a test running on rhodan. If it works and I am still here, 1 will check 

in euterpe.V and do a release of bsrc. 

Jay 

Lisa Robinson wrote (on Sat Oct 1): 
Tim B. Robinson wrote (on Sat Oct 1): 


Jay Tomlinson wrote (on Sat Oct 1): 

I think this is due to the fact that I checked-in but did not release AT, 
because I had a lot of changes and wanted to be protected by the database. When 
I tried to check in euterpe.V, I found out it had been updated (billz change) so 
I updated and re-started my test (which passed). It looks like now someone has 
released AT (probably for placement reasons). But now I need to get Billz BOM 
before I can release. To work around get the previous AT BOM. 
I won't have much time to work on this, but I will get Billz BOM and re-run my 
test to make sure it still works. 

Great if that fixes it, lisar says she can pick up that BOM for AT and 
then release a new top level BOM to back out that change. 

Tim 


Okay, I've picked up at 5.0 and am compiling now. If it runs I'll 
release. 

Thanks 

Lisa R. 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Saturday, October 01, 1994 10:32 PM 

•Jay Tomlinson' 

'lisaf 

Release of BOMs by woody (euterpe) 


Follow Up Flag: Follow up 
Flag Status: Red 

Jay Tomlinson wrote (on Sat Oct 1): 
Checkin Message: 

Simplify PTXC in at, provide a copy of illegal addr excptions to CC to stop NB. AT passes topt. 

BOM Update in euterpe BOM 2.628 

BOM Update in euterpe/verilog BOM 2.477 

BOM Release in euterpe/verilog/bsrc BOM 134.0 

Thanks a lot. 


Tim 
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Subject: 


To: 
Cc: 


From: 
Sent: 


vant [vanthof@hestia] 

Sunday, October 02, 1994 7:44 PM 

'Mark Hofmann'; 'Geert Rosseel'; Tim B. Robinson'; 'Lisa Robinson'; Tom Vb' 
'Dave Van't Hof 
ISS Ivs on euterpe 


The euterpe lvs on ISS finished. Well it died before the compare stage, but after the LINK 
phase completed. The total memory used so far is 1.2BG and it took 32 hours. I don't 
expect the compare phase to take more that a few hours, Which means that even in the state 
the layout is in now, the LVS should take about 1/2 of the time dracula does. 

The big bonus is that once the chip is fully populated, I hope the full chip runtime will 
go down as it won't have all these unused atoms to deal with. 

Plus, I might be able to get runtime down with more studies on the layout hierarchy. 
Not too shaby so far. . 


Thanks 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 


What's great for a snack and fits on your back? It's log, log, log J" 
LOG from BLAMMO! (tm) All kids love Log! # induce 

< std_disclaim . h> 
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From: Mark Hofmann [hopper@tomato] 
Sent: Monday, October 03, 1994 9:14 AM 
To: 'Tim B. Robinson' 
Subject: Re: loads 

Tim B. Robinson writes: 
Are you sure that's all there is to it? If I look at the input edif 
(pre topt), I have an edif file he 1 .edif. The desing name (from the 
verilog) should be just he (ie no passl's anywhere because we haven't 
got that far yet. However: 


tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 487 % make he 1. loads 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/sl 5/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl. edif... 

/n/auspex/sl 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl. edif... 
gmake: *** [hcl.loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 488 % make hcl .loads he 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/sl 5/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl .edif... 

/n/auspex/sl 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl. edif... 
Error! Top level cell :hcl : not found, 
gmake: *** [hcl.loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 489 % make hcl .loads hcl 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/sl 5/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl. edif... 

/n/auspex/sl 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl .edif... 
Error! Top level cell :hcl : not found, 
gmake: *** [hcl.loads] Error 1 

Right- the top-level cell is called "HC" and the edif is called HC1 so there 
is a mismatch. 

-hopper 
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From: Mark Hofmann [hopper@tomato] 
Sent: Monday, October 03, 1994 9:32 AM 
To: Tim B. Robinson' 
Subject: Re: loads 

Tim B. Robinson writes: 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 487 % make he 1. loads 
CHIPROOT=/n/auspex/s 1 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/tools/bin/loads he 1 .edif 
Cleaning crud from Edif file he 1 .edif... 

/n/auspex/sl 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl.edif... 
gmake: *** [he 1. loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/. parent 488 % make he 1. loads he 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/tools/bin/loads he 1 .edif 
Cleaning crud from Edif file hcl.edif... 

/n/auspex/s 1 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl.edif... 
Error! Top level cell :hcl : not found, 
gmake: *** [he 1. loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 489 % make hcl. loads hcl 
CHIPROOT^/n/auspex/sl 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl.edif... 

/n/auspex/s 1 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl.edif... 
Error! Top level cell :hcl: not found, 
gmake: *** [hcl. loads] Error 1 

Right- the top-level cell is called "HC" and the edif is called HC1 so there 
is a mismatch. 

Yes, but I thought the second argument was supposed to deal with that. 
In the examples above I tries all 3 combinations 

loads hcl.edif 
loads hcl. edif he 
loads hcl.edif hcl 

and despite the second argument it still seems to be looking for a top 
level cell called hcl. 

Umm... the 2nd argument to gmake isn't getting passed down to loads, it's 
only seeing the first argument. 

1 don't understand why this ever worked: 

# 

# fannout report 

# 

%.loads: %.edif $(LOADS_PROG) 
$(LOADS) $*.edif 


-hopper 
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From: Tom Laidig [tom@clio] 

Sent: Monday, October 03, 1994 9:41 AM 

To: 'Tim B. Robinson' 

Cc: 'tom@aphrodite'; 'doi@aphrodite'; Vanthof@aphrodite' 
Subject: Re: /n/tmp/chiplog/tbr.mothra.840.euterpe-verilog-bsrc-gf 

Tim B. Robinson writes: 


jl have a .checkoutrc which does: 
I 

|#! /bin/sh 

I 

\TTrrTtWuTTWTrTrtrTTWTr 

|# $Id: .checkoutrc,v 11.1 1 994/09/24 2 1 :24:40 LT tbr Exp $ 
Idir^pwd 1 

[sect^basename $dir* 
j gmake clean 

Igmake GARDSJDISPLAY=clio:0.0 ${sect}gards 2>&1 > gards/makerrs 

|status=$? 

|cat gards/makerrs 

jexit $status 

I 

jwhen this ran it produced the file 

! 

|/n/tmp/chiplog/tbr.mothra.840.euterpe-verilog-bsrc-gf 
I 

|which appears to be garbled and at any rate nothing like the makerrs 
jfile that was left around. There are a couple of places where cat 
jcomplains about a write error, which may have something to do with it. 
[Another odd thing is that the chiplog file has a warning from topt: 


jUnknown command '$' at line 1 while parsing power. tab. local. Ignoring... 
I 

(which I can't see in the makerrs file! I'm certain it's genuine since 
jl found the systax error. I have moved the makers file off to 
|gf/gards/makerrs.840 so i can re-run if you want to take a look. 

Well, one problem is the line 

gmake GARDS_DISPLAY=clio:0.0 ${sect}gards 2>&1 > gards/makerrs 

which first changes stderr to a copy of stdout (which is set to 
/n/tmp/chiplog/...) and _then_ redirects stdout to gards/makerrs. I 
think you want 

gmake GARDS_DISPLAY=clio:0.0 ${sect}gards > gards/makerrs 2>&1 
instead. 
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Tom L 
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From: vant [vanthof@hestia] 

Sent: Monday, October 03, 1 994 1 1 : 07 AM 

To: 'Orlando Hernando'; 'Mike Wageman' 

Cc: 'Dave Van't Hof ; 'Mark Hofmann'; 'Geert Rosseel'; Thomas Laidig'; 'Kurt Wampler 1 ; 'Bruce 

Bateman'; 'B. P. Wong'; 'Fred Obermeier' 
Subject: orchistmpjower drc errors 


The orchistmp lower drc 1 s finished and it's in 

/u/vanthof /compass/mobi/orchis/tapeout/orchistmp_lower . err 

If you have some time this morning, could one of you look at this? 

The floating poly check is still running and should finish in about 3-4 days. 

Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log I # inc luce 

<std disclaim. h> 
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From: 
Sent: 
To: 

Subject: 


Jeff Marr jjeffm@pelorus] 
Monday, October 03, 1994 11:17 AM 
'lisa@pelorus'; 'woody@pelorus'; 'bobm@pelorus' 
Re: itag bits 12:11 


Lisa Repka writes: 

> > I spoke with gmo about this, and I think there was a little confusion. 
> 

> Nay, a *lot* of confusion. ;-) I've got a terpsichore architecture 
spec, 

> a tag layout posted by tim to muse . euterpe, another posted by jay (but 

> seemingly describing only the dtag, though it is not specific) and a 

> micro-architecture spec which nicely numbers the bits but does not 

> name many of them. Out of all that documentation, only Jay's and the 

> uarch's description of the dtag protection field matches. 
> 

> > In the itag, bits 13:0 are the protection field. Bits 13:12 will 
likely 

> > be implemented, and the others (11:0) will not. 
> 

> Did you really mean 13:0 and 13:12 ??? Your last mail was asking 

> about bits 12:11. Also, the uarch does say that bits 12 and 11 cause 

> an exception if set. It also says that those 2 bits are copied 

> directly from the gtlb protection field. The gtlb description says 

> that bit 12 causes an exception if set, and bit 11 is ignored. If bit 

> 12 is set in the gtlb, and causes an exception, how/ when does it get 

> copied into the itag? And is bit 11 ignored on translation, but 

> copied to the itag, where it can then cause an exception? (If so, I 

> wouldn't exactly call that "ignored".) 
> 

> > In the dtag, bits 13:6 are part of the tag, since the dcache is 

> > tagged by the physical address. They have nothing to do with the index. 

> > Bits 5:0 are the protection field. Bits 5:4 and 0 are implemented. 
> 

> Yup. Much less confusion here. 


> Okay. I will implement whatever you like, as long as you tell me, 

> EXACTLY, what that is especially: 
> 

> - Which bits mean what? 

> - If a bit is described as "causes an exception if set", which 

> exception? 

> - If a bit is described as "ignored by the hardware", does that 

> mean it *is* or *isn't* expected to be the same when read as 

> it was when written? 


Ok, I am going to copy woody on this to have him verify, but here goes: 

The gtlb, itag, and dtag have different formats. Oddly enough they are mostly a subset of 
what is specified on page 149 of the Terpsichore System Architecture, dated Apr 14, 1994. 

The gtlb is as specified in the uarch spec. If, for example, bits 14:13 (Caching Control) 
indicate coherent access, then exception 7 is caused on access. If the Detail Access bit 
is set then exception 6 is caused on access. Bits 11:8 can be read and written, but these 
bits have no affect. 

Priv violations (bits 7:0) (Read Access, Write Access, Execute Access, and Gateway Access) 
would cause an exception 5 . 

The dtag (physical data cache tag format) is pretty much as spec'd, except that now bits 
63:48 are not implemented - you will anways read 0. Bit 5 (Caching Control) is related to 


> 


> thanks, 

> lisa 


> 
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exception 3 ; 

bit 4 {Detail Access) to exception 2. 

You cannot cause an exception 1, in this implementation. The dtag inherits the Caching 
Control and Detail Access bit default states, when the entry is created, from the gtlb. 
Bit 0 is the Dirty Bit - this bit is a departure from, rather than a subset of, the TSA. 
You can read and write this bit. 

Other bits in the protection field are unused, but you can read and write them. 
The itag DOES implement bits 63:48, The protection field is bits 13:0. 

Bit 13 (Caching Control) is related to exception 3; bit 12 (Detail Access) to exception 2. 
Other bits in the protection field are unused - but you can read and write them. 
You cannot cause an exception 1, in this implementation. The itag inherits the Caching 
Control and Detail Access bit default states, when the entry is created, from the gtlb. 


Hope this helps, 


jef fm 

P.S. Bob, could you use the terminology specified above. I don't think we need to depart 
from the terminology of the TSA, unless there is a change in meaning. 
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Subject: 


From: 
Sent: 
To: 
Cc: 


Alan Corny [agc@ares] 

Monday, October 03, 1994 12:24 PM 

Tim B. Robinson' 

'Geert Rosseel' 

output of euterpe/verilog/bsrc/nb/.checkoutrc (fwd) 


It appears that we need a machine to act as the server for the gards window, clio refuses 


Forwarded message: 

> From chip@staypuf t Mon Oct 3 09:56:51 1994 

> Date: Mon, 3 Oct 1994 09:55:40 -0700 

> From: chip@staypuf t (Buffalo Chip) 

> Message-Id: <199410031655.JAA24479@staypuft.microunity.com> 

> To: agc@staypuft 

> Subject: output of euterpe/verilog/bsrc/nb/ . checkoutrc 

> 94/10/03 09:48:00 Now attempting to check out a license. 

> Checked out one user token of a gardsconf ig_3 license. 
> 

> Xlib: connection to "clio: 0.0" refused by server 

> Xlib: Client is not authorized to connect to Server 

> Test: Error in opening display = clio: 0.0 GARDS G PLACE 7.126 

> General Placer Copyright (c) 1994 SILVAR-LISCO. All rights reserved. 

> Design: nb-passl Started at: 94/10/03 09:46:00 


> GPLACE Version 7.1.26 of September 9, 1994 


> No component hierarchy found; select by hierarchy disabled. 

> Loading components . . . 

> Loading nets . . . 

> Loading logical types . . . 

> Processing physical types... 

> Loading cell_types . . . 

> Creating net-comp xref table... 

> mv: gards/nb-passl .nof : Cannot access: No such file or directory 

> gmake [2] : *** [gards/nb-passl . nof ] Error 1 

> gmake [2]: Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/nb ' 

> gmake [1] : *** [nb -base . short . nets] Error 1 

> gmake [1] : Leaving directory 

**/N/auspex/root/slO/chip/euterpe/verilog/bsrc/nb ' 

> gmake: *** [nbgards] Error 1 

> [finished at Mon Oct 3 09:55:39 PDT 1994 -- exit status 1] 


> 
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From: Mark Hofmann [hopper@tomato] 

Sent: Monday, October 03, 1994 12:24 PM 

To: 'hardheads@tomato' 

Subject: 5pm Proteus/Euterpe release done 


Please note: proteus/Makef ile . rules has changed (to fix a bug tickled by age on NB) . 

-thanks , 
hopper 
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Sent: 
To: 

Cc: 


From: 


Jay Tomlinson [woody@melpomene] 
Monday, October 03, 1994 12:51 PM 
'Jeff Marr' 


Subject: 


'lisa@pelorus'; 'euterpe@melpomene' 
Re: itag bits 12:11 


Jeff Marr wrote {on Mon Oct 3) : 

Ok, I am going to copy woody on this to have him verify, but here goes: 

The gtlb, itag, and dtag have different formats. Oddly enough they are mostly a 
subset of what is specified on page 149 of the Terpsichore System Architecture, 
dated Apr 14, 1994. 

The gtlb is as specified in the uarch spec. If, for example, bits 14:13 (Caching 
Control) 

indicate coherent access, 

then exception 7 is caused on access. If the Detail Access bit is set then exception 6 

is 

caused on access. Bits 11:8 can be read and written, but these bits have no affect. 
Priv violations (bits 7:0) (Read Access, Write Access, Execute Access, and Gateway 
Access) 

would cause an exception 5. 

The dtag (physical data cache tag format) is pretty much as spec'd, except that now 
bits 63:48 are not implemented - 

you will anways read 0. Bit 5 (Caching Control) is related to exception 3; 
bit 4 (Detail Access) to exception 2. 

You cannot cause an exception 1, in this implementation. The dtag inherits the 
Caching Control and Detail Access bit default states, when the entry is created, from 

the 

gtlb. Bit 0 is the Dirty Bit - this bit is a departure from, rather than a subset of, 
the TSA. You can read and write this bit. 

Other bits in the protection field are unused, but you can read and write them. 

"inherits" here really means that it is written to O'b when the entry is created. This is 
because if the corresponding gtlb bit is set then an exception would be caused and the tag 
entry is not created. The other bits of the protection field are also written to zero at 
creation. 

The itag DOES implement bits 63:48. The protection field is bits 13:0. 
Bit 13 (Caching Control) is related to exception 3; bit 12 (Detail 
Access) to 

exception 2 . Other bits in the protection field are unused - but you can read and 
write them. 

You cannot cause an exception 1, in this implementation. The itag inherits the 
Caching Control and Detail Access bit default states, when the entry is created, from 


The itag format cannot be as described in the TSA because we are supporting a 4k cache. 
This requires that bits 13:12 be part of the virtual address. This leaves us with 11:0 as 
protection. I propose that we use 5:4 to be the Cache Control and Detail Access bits so 
that it is the same as the dtag. The same note about "inherits" as with the dtag. 


the 


gtlb. 


Jay 


Hope this helps, 


jef fm 
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From: Jay Tomlinson [woody@melpomene] 

Sent: Monday, October 03, 1994 12:57 PM 

To: Tim B. Robinson' 

Cc: 'Jeff Marr'; 'gmo@melpomene'; 'euterpe@melpomene' 

Subject: illegal address exceptions 


Tim B. Robinson wrote (on Fri Sep 30) : 
Jay Tomlinson wrote (on Fri Sep 30) : 


file 


map) 


Jeff Marr wrote (on Fri Sep 30) : 
Jay Tomlinson writes: 

> Jeff, 
> 

> You asked me earlier about illegal address exceptions. I looked at the code to 

> be sure and as I suspected, this type exception will not prevent a register 

> write and it will not inhibit an NB request. 

> The cases covered are : 

> 680.. 0 - 7f..f (between cerberus and on-chip) 

> pa [63: 48] ~= 0 

> pa [47] & not (one of the on-chip resources listed in the memory 
> 

> Let me know if you need more information. 
> 

> Jay 

What is going to happen when the NB request completes? What are the side 
affects? 


Thanx, 
j ef f m 


The NB request won't complete, because as far as I know these illegal address 
are not recognized by any of the NB peripherals. This means that there is now 1 
less NB entry available. 

The assumption here is that a reset must be done after this exception. This is 
intended as a debug aid. That is what gmo said when he request that we change 
this from a machine check to an exception. This change was request made so that 
SW could find the problem by looking at the exception information. 

Whoai If we need a rest to fix this up then it should be a machine 
check not an exception. If it's going to be an exception then we need 
to do it right. 


Tim 


We found a cheap way to prevent these from going to NB. NB will not be started now when an 
illegal address exception occurs. 


Jay 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Jay Tomlinson [woody@melpomene] 
Monday, October 03, 1994 1:30 PM 
'craigtgaphrodite' 
'euterpe@aphrodite' 
GTLB Access 


This will be implemented. 

The It lb hardware will be changed so that the mask field will always read as 1 1 s and 
ignored on write. The gtlb hardware will remain as described below. 
Tim's mail is included for refenence. 


Tim B. Robinson wrote (on Thu Sep 29) : 

We have run into a problem with the GTLB mask field. When the LTLB 
was changed to implement only the XOR field, craig wanted the sense of 
the mask field inverting so that the LTLB mask would be read only with 
a value of 0 rather than all l's. To be consistent with this, the 
GTLB definition was to be changed too, with the thinking being that 
all we had to do was reverse the sense of the data going in and out 
via the CMOS read/write ports. However, the GTLB physical array uses 
the same I/O pins for the mask and match arrays, efectively selecting 
between them with an additional address bit. So we cannot invert one 
without inverting the other unless we add more logic which we can ill 
afford in order to invert the data selectively. 

I therefore propose that we go back to the original (and less 
confusing) definition, with the LTLB match field reading back always 
all l's and no extra inversions in the GTLB path. I think this can 
still be justified as consistent with the general definition of 
reserved fields always reading zero, because this is not really a 
reserved fieled. It is the LTLB match field, which in this 
implementation happens to have a reserved *value* of all l's which you 
can't change. 

Comments please - and remember atoms are at stake! 


Jay 


Tim 
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Sent: 

To: 

Cc: 


From: 


Jay Tomlinson [woody@melpomene] 
Monday, October 03, 1994 1:36 PM 
'Jeff Man-' 
'euterpe@gaea' 


Jeff Marr wrote (on Mon Oct 3) : 

In article <199410031750.KAA28365@melpomene.microunity.com>, 
woody@melpomene.microunity.com (Jay Tomlinson) writes: 

I 

| > The itag format cannot be as described in the TSA because we are supporting a 4k 
|> cache. This requires that bits 13:12 be part of the virtual address. 
This leaves 

j> us with 11:0 as protection. I propose that we use 5:4 to be the Cache Control 
j> and Detail Access bits so that it is the same as the dtag. The same note about 
|> "inherits" as with the dtag. 

I just talked to tbr, and found out that we will need the execute access field in the 
tag - 

to avoid needing to get it from the gtlb on a hit. So, ya need a coupla bits. How about 
2:1? 

Tim explained this to me and he is correct. Bits 2:1 are as good as any. 
Jeff "Won't you be my ' lectronic neighbor?" Marr 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Monday, October 03, 1994 3:1 1 PM 
To: 'billz@nosferatu' 
Cc: 'jeffm@nosferatu'; 'tbr@nosferatu' 
Subject: 128 bit stores 

Bill 

It looks like 128bit stores to dram failing because the 2 octlets are 
being stored in the wrong order. 

There is a trace dram_store_unique_0.log and dram_store_unique,vrlog 
on /n/rhodan/s3/euterpe/verilog/bsrc that illustrates this. 

Lisa R. 
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From: tbr 

Sent: Monday, October 03, 1994 3:23 PM 

To: Tom Laidig' 

Cc: , doi@aphrodite'; 'tom@aphrodite'; Vanthof@aphrodite' 

Subject: Re: /n/tmp/chiplog/tbr.mothra.840.euterpe-verilog-bsrc-gf 
Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Mon Oct 3): 
Tim B. Robinson writes: 


j I have a .checkoutrc which does: 

I 

\m /bin/sh 

I 

\mmmmmmmmmnmmmmmmmmmmmmmmmmm 

|# $Id:.checkoutrc,vll.l 1994/09/24 21:24:40 LT tbr Exp $ 

!################################ 

jdir^pwd' 

Isect^basename $dir 
Igmake clean 

Igmake GARDS_DISPLAY=clio:0.0 ${sect}gards 2>&1 > gards/makerrs 

|status=$? 

jcat gards/makerrs 

j exit $status 

I 

|when this ran it produced the file 

I 

|/n/tmp/chiplog/tbr.mothra.840.euterpe-verilog-bsrc-gf 
I 

|which appears to be garbled and at any rate nothing like the makerrs 
j file that was left around. There are a couple of places where cat 
jcomplains about a write error, which may have something to do with it. 
jAnother odd thing is that the chiplog file has a warning from topt: 


jUnknown command T at line 1 while parsing power. tab. local. Ignoring... 

i 

| which 1 can't see in the makerrs file! I'm certain it's genuine since 
jl found the systax error. I have moved the makers file off to 
jgf/gards/makerrs.840 so i can re-run if you want to take a look. 

Well, one problem is the line 

gmake GARDS_DISPLAY=clio:0.0 ${sect}gards 2>&1 > gards/makerrs 

which first changes stderr to a copy of stdout (which is set to 
/n/tmp/chiplog/...) and _then_ redirects stdout to gards/makerrs. I 
think you want 
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gmake GARDS_DISPLAY=clio:0.0 ${sect}gards > gards/makerrs 2>&1 
instead. 

Thanks, yes doi pointed that out, and we fixed 'em. 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 03, 1994 3:30 PM 
'Alan Cony' 

'Geert Rosseel'; 'tom@aphrodite' 

output of euterpe/verilog/bsrc/nb/.checkoutrc (fwd) 


Alan Corry wrote (on Mon Oct 3) : 

It appears that we need a machine to act as the server for the gards 
window, clio refuses .... 


Forwarded message : 

> From chip@staypuf t Mon Oct 3 09:56:51 1994 

> Date: Mon, 3 Oct 1994 09:55:40 -0700 

> From: chipostaypuf t (Buffalo Chip) 

> Message-Id: <199410031655 . JAA24479@staypuf t .microunity . com> 

> To: agc@staypuft 

> Subject: output of euterpe/verilog/bsrc/nb/ . checkoutrc 

> 94/10/03 09:48:00 Now attempting to check out a license. 

> Checked out one user token of a gardsconfig _3 license. 
> 

> xlib: connection to "clio: 0.0" refused by server 

> Xlib: Client is not authorized to connect to Server 

> Test: Error in opening display = clio: 0.0 

> GARDS GPLACE 7.126 -- General Placer 

> Copyright (c) 1994 SILVAR-LISCO . All rights reserved. 

> Design: nb-passl Started at: 94/10/03 09:46:00 


> GPLACE Version 7.1.2 6 of September 9, 1994 


> No component hierarchy found; select by hierarchy disabled. 

> Loading components . . . 

> Loading nets . . . 

> Loading logical types... 

> Processing physical types... 

> Loading cell_types . . . 

> Creating net-comp xref table... 

> mv: gards/nb-passl .nof : Cannot access: No such file or directory 

> gmake[2]: *** [gards/nb-passl .nof ] Error 1 

> gmake[2] : Leaving directory 
VN/auspex/root/slO/chip/euterpe/verilog/bsrc/nb 1 

> gmake[l]: *** [nb-base . short .nets] Error 1 

> gmake[l] : Leaving directory 
"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/nb • 

> gmake: *** [nbgards] Error 1 

> [finished at Mon Oct 3 09:55:39 PDT 1994 -- exit status 1] 


Clio is tom's machine so I'm surprised if it's down now he's back. 
Tom, any idea what's goign wrong? 


Tim 
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From: Derek Iverson [doi@demeter] 
Sent: Monday, October 03, 1 994 3:38 PM 
To: Tim B. Robinson' 
Subject: cvs question 

Tim B. Robinson writes: 

> 

> I have a file 'hc_fifo8ctrl.pia' which started life as 

> 'hc_fifo5ctrl.pla'. 

> At some point, I copied it over, modified it, then cvs added the new 
>file. 

> 

> However, the header still has: 

> /* $Id: hc_fifo5ctrl.pta,v 1.3 1994/02/10 10:23:05 LT tbr Exp $ %T% */ 

> 

> Isn't the part between the $'s supposed to get re-written each time 

> it's updated. 

Yes, I thought so. I did a little test case and it worked for me. 

Where is the file located? I looked in euterpe/verilog/bsrc/hc and 
couldn't find a file of that name. 

doi 
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From: 


tbr 


To: 


Sent: 


Monday, October 03, 1994 4:08 PM 
'Mark Hofmann' 


Subject: 


loads 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofmann wrote (on Mon Oct 3): 


hi tim, 

i found the problem, the exit code 1 is because loads is looking for 
a top-level design called "foo-passl " when it should look for "foo". 
loads can be invoked with 2 arguments: "loads gards/foo-passl.edif foo" 
where the 2nd argument geives the design name. 

i*H make the error more explicit. 

i'll also see if i can get loads to figure out the design name so the 2nd 
argument isn't needed 

Are you sure that's all there is to it? If I look at the input edif 
(pre topt), I have an edif file he 1 .edif. The desing name (from the 
verilog) should be just he (ie no passl's anywhere because we haven't 
got that far yet. However: 


tbr@godzilla -/euterpe/verilog/bsrc/hc/gards/, parent 487 % make hcl .loads 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/tools/bin/loads he 1 .edif 
Cleaning crud from Edif file hcl .edif... 

/n/auspex/s 15/tbr/euterpe/tools/bm/hnf: Reading Edif file hcl.edif... 
gmake: *** [hcl.loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 488 % make hcl .loads he 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/tools/bin/loads he 1 .edif 
Cleaning crud from Edif file hcl .edif... 

/n/auspex/s 1 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl.edif... 
Error! Top level cell :hcl: not found, 
gmake: *** [hcl.loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/. parent 489 % make hcl.loads hcl 
CHIPROOT=/n/auspex/s 1 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl.edif... 

/n/auspex/s 1 5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl.edif... 
Error! Top level cell :hcl: not found, 
gmake: *** [hcl.loads] Error 1 
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From: tbr 

Sent: Monday, October 03, 1 994 4:17 PM 

To: 'Derek Iverson' 

Subject: cvs question 

Follow Up Flag: Follow up 
Flag Status: Red 


Derek Iverson wrote (on Mon Oct 3): 

Tim B. Robinson writes: 

> 

> I have a file 'hc_fifo8ctrl.p1a* which started life as 

> 'hc_fifo5ctrl.pla\ 

> At some point, I copied it over, modified it, then cvs added the new 
>file. 

> 

> However, the header still has: 

> /* $Id: he Jifo5ctrl.pla,v 1 .3 1994/02/10 10:23:05 LT tbr Exp $ %T% */ 

> 

> Isn't the part between the S's supposed to get re-written each time 

> it's updated. 

Yes, I thought so. I did a little test case and it worked for me. 

Where is the file located? I looked in euterpe/verilog/bsrc/hc and 
couldn't find a file of that name. 

OK, my problem. I have a file locally called hc_fifo8ctrl.pla which I 
thought was the source. I know 1 got that by copying the other file. 
However, for some reason I then decided to rewrite it in a different 
source language, so the version in the repository is 
hc_fifo8ctrl.Veqn and I am looking at an obsolete file that was never 
comitted. 

Sorry to waste your time (though it probably took less of your time to 
put a finger on the problem than it would have of mine!) 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Monday, October 03, 1994 5:48 PM 

Tim B. Robinson 1 

'agc@ares'; 'geert@ares'; 'tom@aphrodite' 

Re: output of euterpe/verilog/bsrc/nb/.checkoutrc (fwd) 


Tim B. Robinson writes: 

Alan Corry wrote (on Mon Oct 3) : 

It appears that we need a machine to act as the server for the gards 
window, clio refuses .... 

Clio is tora's machine so I'm surprised if it's down now he's back. 

Tom, any idea what 1 s goign wrong? 

Well, someone already turned off access control on clio's x server, so you probably know 
that that was the problem. 


Tom L 
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From: 
Sent: 
To: 

Subject: 


Tom Vo [vo@merope] 

Monday, October 03, 1994 6:21 PM 

'Geert Rosseel' 

Wafer probing of euterpe (fwd) 


John Mudge wrote .... 

>From mudge@hera Mon Oct 3 16:13:22 1994 
>Date: Mon, 3 Oct 1994 16:13:20 -0700 
>From: mudge@hera (John Mudge) 

>Message-Id: <19941003 2313 . QAA11331@hera . raicrounity . com> 
>To: vo@hera, andrew@hera, jeffohera, warrenOhera 
>Subject: Wafer probing of euterpe 
>Cc : mudge@hera 
> 

>Each, 

>We would like to understand what is on the euterpe pad ring, where the 

>power poles are, what is needed to minimally power the device at wafer 

>sort and what the power requirements are. There will be 

a meeting to discuss this at 11:00 a.m. tomorrow (Tuesday) in PECR. 

> 

>Tom, 

>Please bring along any visual material that you have. If there is 
>anybody else from the design group that should be there, would you pass 
>the word along. 

> 

> j ohnnymudge 


> 
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From: Tom Laidig [tom@clio] 

Sent: Monday, October 03, 1994 6:28 PM 

To: 'Derek Iverson' 

Cc: 'tom@demeter'; 'tbr@demeter' 

Subject: Re: forwarded message from Rich McCauley 

Derek Iverson writes: 
I 

[Is this something we can avoid with some ' incompat' rules? 

Well, perhaps something like 

incompat 
proteus 

euterpe/verilog/bsrc; 

if that makes anything under proteus incompatible with anything under 
euterpe/veri log/bsrc. 

That should fix any problems with changes in proteus affecting gards 
builds under /u/chip. The problem of messing up a local build is 
harder... perhaps we could set up some time-locking mechanism for builds 
under /u/chip/proteus. 

I guess we could fake this with the incompat mechanism by having some 
dummy (toplevel, unfortunately) directory that we said was incompatible 
with proteus. Then have some at job that fires off a release in this 
directory every lOAm and 5PM. Each release could involve the checkin 
of a file containing a time (a 10AM release would contain the time of 
5PM that day; each 5PM release would contain the time of 10AM the next 
day). Then the .checkoutrc in this directory would simply sleep until 
the time specified in the timestamp file. The end result would be that 
people could release at any time, but the releases would be blocked 
until 10AM or 5PM. Then all the queued up releases would run, followed 
by the blocking release. Ooohhh! Ain't it ugly? 


jdoi 
I 

J Start of forwarded message 

|From: rich@pegasus (Rich McCauley) 

|To: agc@ares 

|Cc: hardheads@pegasus 

jSubject: Re: releases in proteus 

I 

|Sorry about that. I had some notion that something bad might occur but only 
jafter I'd actually started the release. I released in libsrc which is custom 
jso somehow I had the notion that wouldn't screw anyone up. Sorry for the 
[inconvenience and wasted time. 

I 

| rich 


j> From: agc@ares (Alan Corry) 
|> Subject: releases in proteus 
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[> To: rich@ares (Rich McCauley) 
l> 

|> Just a reminder that you shouldn't do any releases in 
j> proteus at any times other than 10:00am and 5:00pm. 

I> 

|> Your recent release caused all GARDS users to be reset, 

|> as well as affecting all other GARDS jobs that were currently 

|> running in the chipq. 

l> 
l> 

| E n d 0 f forwarded message 

I 


Tom L 
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From: Jay Tomlinson [woody@melpomene] 
Sent: Monday, October 03, 1994 6:54 PM 
To: 'lisartgmelpomene'; 'tbr@melpomene' 
Subject: exmaskeasy bug 

Lisa, 

The problem is that the 'flchirq' interface was recently added. This signal will 
set an interrupt when set. See the mail below. It is undriven in the dump file 
that I looked at. 

Tim is this bit supposed to be maskable? 
Jay 

From: tbr@aphrodite (Tim B. Robinson) 

To: dickson@aphrodite, agc@aphrodite, woody@aphrodite 

Subject: interrupts from cerberus 

Date: Fri, 30 Sep 1994 08:58:39 -0700 


Rich, can you figure out how to do this please? I think all we need 
is to take bit 61 from octlet 6 and or it into bit 1 of the forceval 
input to sr. You may need a synchronizer. I would also like this to 
get ored with the extra padring input alan defined ot allow us to get 
interrupts from an external PCMCIA adapter chip if we ever neeeded to. 
Again it seems like a simple OR function on the cmos side could do 
this. (Jay, we need to be sure the main board netlist has that pin 
strapped to the inactive state.) 

There has been a strong request to be able to cause an event in 
euterpe from an external Cerberus master to support bringup and debug. 
We will implement this using bit 61 of cerberus octlet 6 (defined as 
the unimplemented self test bit), which assignment has craig's 
blessing. Setting this bit will result in bit 1 of the event register 
being set. Acknowledging this event will require rewriting Cerberus 
octlet 6 to clear the bit there before clearing bit 1 in the event 
register. 

When not required to support debug in this way (ie assuming bit 61 
in octlet 6 is always 0), bit 1 of the event register can be used for 
normal interrupts from Calliope. 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@ghidra] 
Monday, October 03, 1994 7:08 PM 
'geert@ghidra' 

output of euterpe/verilog/bsrc/cj/.checkoutrc 


The output from euterpe/verilog/bsrc/cj /. checkoutrc is 144k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . ghidra .29009 . euterpe-verilog-bsrc-cj 

(which is accessible from all machines). This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: Buffalo Chip [chlp@rhea] 

Sent: Monday, October 03, 1994 7:12 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cj BOM 58.0 initiated by geert completed @ Mon Oct 3 17:08:28 
PDT 1994 with exit status 0 . . chip 
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From: geert (Geert Rosseel) 

Sent: Monday, October 03, 1 994 7:17 PM 

To: 'bill'; 'bpw'; 'geert'; 'ong'; 'solo'; 'stick'; 'wingard' 

Subject: CMOS design meeting .. 


HI, 

Since the Xilinx project is goiing to be on hold, the next big project is the design of a 
CMOS design methodology / library. Think of it as designing a CMOS euterpe. 

Let's meet tomorrow Tuesday at 2:00 p.m. to start this project ... 

Tuesday 2:00 p.m. Hardware Conference Room 


Geetr 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 03, 1 994 7:53 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/dr BOM 37.0 initiated by age completed ® Mon Oct 3 17:49:31 
PDT 1994 with exit status 1.. chip 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 03, 1994 8:22 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/dr BOM 38.0 initiated by age completed @ Mon Oct 3 18:19:06 
PDT 1994 with exit status 1.. chip 
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From: 


tbr 


To: 


Sent: 


Monday, October 03, 1994 8:36 PM 
'Mark Hofmann' 


Subject: 


Re: loads 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofmann wrote (on Mon Oct 3): 

Tim B. Robinson writes: 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 487 % make he 1. loads 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/s 15/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl. edif... 

/n/auspex/sl5/tbr/euterpe/tools/bin/hnf: Reading Edif file hcl. edif... 
gmake: *** [hcl. loads] Error 1 

tbr@godzilla-/euterpe/verilog/bsrc/hc/gards/.parent 488 % make hcl. loads he 
CHIPROOT=/n/auspex/s 1 5/tbr/euterpe /n/auspex/s 1 5/tbr/euterpe/too Is/bin/loads he 1 .edif 
Cleaning crud from Edif file hcl .edif... 

/n/auspex/s 1 5/tbr/euterpe/tools/bin/hnf: Reading Edif file he 1. edif... 
Error! Top level cell :hcl: not found, 
gmake: *** [hcl. loads] Error 1 

tbr@godzilla ~/euterpe/verilog/bsrc/hc/gards/.parent 489 % make hcl. loads hcl 
CHIPROOT=/n/auspex/sl 5/tbr/euterpe /n/auspex/s 15/tbr/euterpe/tools/bin/loads hcl .edif 
Cleaning crud from Edif file hcl. edif... 

/n/auspex/s 15/tbr/euterpe/tooIs/bin/hnf: Reading Edif file hcl. edif... 
Error! Top level cell :hcl: not found, 
gmake: *** [hcl. loads] Error 1 

Right- the top-level cell is called "HC" and the edif is called HC1 so there 
is a mismatch. 

Yes, but 1 thought the second argument was supposed to deal with that. 
In the examples above I tries all 3 combinations 

loads hcl. edif 
loads hcl. edif he 
loads hcl. edif hcl 

and despite the second argument it still seems to be looking for a top 
level cell called hcl. 

Umm... the 2nd argument to gmake isn't getting passed down to loads, it's 
only seeing the first argument. 

I don't understand why this ever worked: 


# fannout report 

# 

%.loads: %.edif $(LOADS__PROG) 
$(LOADS) $*.edif 

We never used to rename the edif file (several generations back). I 
actually ran the command by hand to get the second argument through 
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and it still did not work. I see your later messages, and indeed it 
does work now. 

Thanks. 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Karzes [karzes@MicroUnity.com] 
Monday, October 03, 1994 8:54 PM 

'tbr@MjcroUnity.com'; 'dickson@MicroUnity.com'; 'abbott@MicroUnity.com' 

Vo@MicroUnity.com' 

XLU status 


Tom Vo and I met tonight to discuss the XLU f anout/placement status. 
After 

the meeting I removed xlu.c from the Makefile and cvs file list, and replaced it with 
xlu.v which can now be maintained by hand. 

The current status is as follows: 

o I have corrected all fanout problems for the inputs to the final 
ff/muxff gates which drive the emitter followers. I have also 
indicated in the names for these signals whether they should be 
placed on the left or right size of the XLU. 

o All constants (cOl) in the XLU have also had their fanouts 

corrected. Usage has been grouped to sorrespond to placement. 

o I have outlined a general placement strategy (left vs. right 
side) for the major pieces of control logic (including all of 
the PLAs) . 

o Higher level control fanout, including input to the PLAs , still 
needs to be corrected. 

At this point I don't feel it is necessary for me to make the final changes. 
There are a number of changes to be made, and they will take some time to make, but they 
should all fall into the general category of making copies of existing signals, some of 
which will need to be shipped to the far side of the XLU. I do not believe any timing 
changes will need to be made. 

I also examined the and-plane fanout of all of the XLU PLAs. It actually looks pretty 
good. There are only 2 PLAs which have and- terms with fanouts greater than 8: 

xlu_sr_r2 : 1 with 9, 2 with 10, 1 with 15 
xlu_sr_r3 : 1 with 10 

It may be possible that this will work with not change, but if not then it should 
hopefully be fairly easy to correct these isolated cases. I can provide more detail on 
this if needed. 

On the other hand, many of the PLAs generate high fanouts on the primary input signals. 
This needs to be corrected, but in all cases there should be enough time to create the 
additional copies needed. It's really a matter of mechanics for modifying the PLAs and 
xlu.v. in some cases, small vectors 

{7 bits or less) are used as inputs to the PLAs . In some of these cases, the input 
loadings vary significantly from one bit to the next. Since verilog doesn't support 
jagged arrays (or multidimensional arrays of any sort for that matter) , it may be 
necessary to change these vectors into sets of scalars in order to do a good job of 
reducing the fanout. Again, these should be simple though tedious changes to make. 

I currently have a set of tests which exercise all of the functional componets of the XLU 
directly. These tests take around 1.5 hours to run on a Sparc 10. I will probably 
continue to run these tests periodically myself, but if anyone wants their own copy I can 
make them available. 

I will, of course, continue to be available to answer any questions or discuss any issues 
which might arise in the XLU design and placement. 

The following is a set of placement notes which I gave Tom Vo. The PLAs are shown both by 
themselves and in context. All of the larger groups of gates are also shown. Note that 
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"12" indicates the left side, while both "n" 
and 

"3" indicate the right side. 

I have structured things in such a way that it should never be necessary to run a signal 
from the "12" (left) side to the "3" (right) side. It would be a good idea to 
periodically check that this condition holds. Failure to follow it will result in an 
unnecessarily high atom count and a more complicated design. 


Key: 

n = "near" side (close to registers & bypass) 

12 = Stage l/Stage 2 side 

3 = Stage 3 side 


name 

place 

function 


xlu_tr_sl 

12 

tr 

stage l 

row/column pre-control 

xlu_tr_s2 

12 

tr 

stage 2 

row/column pre- control 

xlu_tr_s3 

3 

tr 

stage 3 

row/column pre- control 

xlu_sr_rv 

n 

sr 

row pre- 

-control 

xlu_sr_cv 

n 

sr 

column pre -control 

xlu_sr_r2 

12 

sr 

stage 2 

row control 

xlu_sr c2 

12 

sr 

stage 2 

column control 

xlu_sr_r3 

3 

sr 

stage 3 

row control 

xlu_sr_c3 

3 

sr 

stage 3 

column control 

xlu_la_r2 

12 

la 

stage 2 

row control 


xlu mixed 

tr_control mixed 

tr_sl 12 

tr_s2 12 

tr_s3 3 

tr_al_4a 12 

tr_a2_4a 12 

tr_bl_5a 12 

tr_b2_5a 12 

tr_cl_6a 3 

cr__control 12 

sr_masks n 

sr_control mixed 

sr_rv n 

sr_cv n 

sr_r2 12 

sr_c2 12 

sr_r3 3 

sr_c3 3 
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sr_ccl_6a 

3 

sr_cc2_6a 

3 

sr_cc3_6a 

3 

sr rcl 6a 

3 

sr_rc2Ja 

3 

sr rc3_6a 

3 

sr_rc4_6a 

3 

la_control 

mixed 

la_r2 

12 

la ccl_6a 

3 

la_rcl_6a 

3 

sa_control 

n 

csla_5a 

12 

cla 5a 

12 

clb_5a 

12 

cs2a 6a 

12 

c2a_6a 

12 

c2b_6a 

12 

cs3a_7a 

3 

cs3b_7a 

3 

cs3c_7a 

3 

cs3d_7a 

3 

cs3e_7a 

3 

c3a 7a 

3 

c3b_7a 

3 

c3c_7a 

3 

zs3a 7a 

3 

zs3b_7a 

3 

zs3c_7a 

3 

zs3d 7a 

3 

z3b_7a 

3 

z3c_7a 

3 

ctrldata 

mixed 

db_7a 

12 

dc_8a 

12 

q_9a 

3 


emitter- follows placed as appropriate (same side as input gates) 


Note: For final ff/muxff select and data inputs, left vs. right placement 

should be based on the signal name. If a particular class is indicated 
(e.g., cs2, c3, zs3, etc.), then placement should be on the 
corresponding side. Otherwise, if sl2 is present in the name, then 
it should be placed on the 12 side. Otherwise, it should be placed 
on the 3 side. This only applies to the final ff/muxff select and 
data inputs. Inputs for the other parts of the control have not 
yet been partitioned in this manner. 
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From: tbr 

Sent: Monday, October 03, 1994 9:07 PM 

To: 'Derek Iverson' 

Cc: 'torrKgdemeter' 

Subject: forwarded message from Rich McCauley 
Follow Up Flag: Follow up 

Flag Status: Red 


Derek Iverson wrote (on Mon Oct 3): 


Is this something we can avoid with some incompat' rules? 
doi 

Start of forwarded message 

From; rich@pegasus (Rich McCauley) 

To: agc@ares 

Cc: hardheads@pegasus 

Subject: Re: releases in proteus 

Sorry about that. I had some notion that something bad might occur but only 
after I'd actually started the release. I released in libsrc which is custom 
so somehow I had the notion that wouldn't screw anyone up. Sorry for the 
inconvenience and wasted time. 

rich 


> From: agc@ares (Alan Corry) 

> Subject: releases in proteus 

> To: rich@ares (Rich McCauley) 

> 

> Just a reminder that you shouldn't do any releases in 

> proteus at any times other than 10:00am and 5:00pm. 

> 

> Your recent release caused all GARDS users to be reset, 

> as well as affecting all other GARDS jobs that were currently 

> running in the chipq. 

> 
> 

Partly. If we prevent any release in proteus when there is a release 
underway in euterpe that would help, but it also affects anybody 
working locally on euterpe who is using the common proteus. The only 
way we know to mitigate is to co-ordinate the times of releases so 
people know when to ecpect trouble. 

Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 03, 1994 9:45 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/nb BOM 63.0 initiated by age completed @ Mon Oct 3 19:43:50 
PDT 1994 with exit status 1.. chip 
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To: 


Subject: 


Sent: 


From: 


tbr 

Monday, October 03, 1994 10:15 PM 

'hopper' 

another nit 


Follow Up Flag: Follow up 
Flag Status: Red 


If I ask loads to run on a non-existant file: 

tbr@rhodan ~/euterpe/verilog/bsrc/hc/gards 423 % loads hc-passl.edif 
egrep: hc-passl.edif: No such file or directory 
Cleaning crud from Edif file hc-passl .edif... 
/u/chip/tools/bin/hnf: bad arg to -topcell option 
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From: 


tbr 


To: 

Subject: 


Sent: 


Monday, October 03, 1994 10:50 PM 
'Jay TomlinsorV 
l-Cache Control 


Follow Up Flag: Follow up 
Flag Status: Red 

Jay Tomlinson wrote (on Mon Sep 12): 
Mark, Bill, 

Following is what I think is the bulk of what needs to be done in order to 
implement I-cache operations. I am willing to bet that I missed something, but 
in general tried to point at the major function that needs to be added. 

Let me know if you think of anything that should be on the list. 


I-Cache Operations: 

The itag is accessed/checked when the instruction is actually being executed. 
This means that if ciMiss then the current instruction must be cancelled and 
ife'ing of that cylinder will be stopped. The nb request to fetch the icache 
line cannot be initiated by this flow because ife does not have access to its 
physical address. Therefore, a 'psuedo-branch'(BFetch) flow must be generated by 
UU in response to the ciMiss. This flow will use the NRMLEX access type which 
will enable translation, exceptions, and the 1st NB request to occur. This means 
that the phys address will be created. 3 more NB requests must be generated to 
complete the cache line. The initial NB request that is generated by LT must set 
the CACHE bit to 1 and also set the ICACHE/! DC ACHE bit to 1 . These bits will be 
used by CC to generate the NB request necessary to complete the ICACHE line. 

When each requests NB data returns, UU will generate a 'psuedo-op' (SN128WrtI) 
that load will from NB and stores to the IBUF (an NB request). This job's access 
type will use an access type that disables exception reporting. UU must also 
generate a control signal that will force LT to convert the address (cache 
index?,ifp?) into the appropriate IBUF physical address. NB must guarantee that 
the store request will be accepted. Otherwise the store data will be lost. 

The IBUF write control logic (gt/gtsnake) will generate a signal that indicates 
IBUF write & pbb<CACHE>=l. This will be used by CC to determine when the last 
octlet has been written which will trigger the write of the ITAG. This will also 
signal IFE that the appropriate cylinder can continue execution. 

Load/Store conflict detection must be performed to guarantee correct SRAM 
operation. This will be done adding a comparator in CJ that compares the read 
and write addresses. The controls from gt/gtsnake will be used to validate the 
compare result. When a conflict is detected, the IFE will be notified. IFE will 
ignore the data and re-fetch the line that got the conflict. 


thanks, 
Jay 


Actions: 
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woody: 

1 . add a block to generate the ciMiss and perform itag protection checking. 

2. add ctioi and new block to euterpe.V 

3. add necessary logic to LTto 'generate' IBUF physical address. 

4. modify LT, if needed, to perform translation and exception checking/reporting 
for access type == NRMLEX. 

5. modify LT to perform translation and exception checking/no reporting for 
access type = TRGTEX. 

6. modify LT to set nbcin CACHE and ICACHE/1DCACHE bits. 

7. modify GTsnake logic to send notification that I-cache write completed. This 
is sent to CC to trigger the I-cache tag write. 

8. Add load/store conflict detection logic to CJ. 

billz: 

1 . modify CC to generate NB requests for I-cache misses. 

2. modify CC to write I-cache tag. 

3. modify CC to notify IFE that I-cache tag has been written. 

4. modify NB to guarantee that IBUF store request will capture an NB entry. 

mws: 

1 . modify IFE to stop fetching (only appropriate cylinder) following a cache 
miss. Signal from CC will re-enable instruction fetching. 

2. modify UU to add BFetch instruction for initiating the NB requests 
for the I-cache miss. 

3. modify UU to add SN128WrtI instruction to receive NB data and send controls 
to LT to generate an IBUF store NB request. 

4. modify UU to support I-fetch tag and GTLB exceptions. 

5. modify IFE to re-fetch line when CJ detects a load/store conflict. 


What's your understanding of how far down this list we currently are? 
Tim 
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From: Jay Tomlinson [woody @demeter] 
Sent: Monday, October 03, 1 994 1 1 :24 PM 
To: 'Tim B. Robinson' 
Subject: l-Cache Control 


Tim B. Robinson wrote (on Mon Oct 3): 
Jay Tomlinson wrote (on Mon Sep 12): 
Mark, Bill, 

Following is what I think is the bulk of what needs to be done in order to 
implement I-cache operations. I am willing to bet that I missed something, but 
in general tried to point at the major function that needs to be added. 

Let me know if you think of anything that should be on the list. 

thanks, 
Jay 


I-Cache Operations: 

The itag is accessed/checked when the instruction is actually being executed. 
This means that if ciMiss then the current instruction must be cancelled and 
ife'ing of that cylinder will be stopped. The nb request to fetch the icache 
line cannot be initiated by this flow because ife does not have access to its 
physical address. Therefore, a 'psuedo-branch'(B Fetch) flow must be generated by 
UU in response to the ciMiss. This flow will use the NRMLEX access type which 
will enable translation, exceptions, and the 1st NB request to occur. This means 
that the phys address will be created. 3 more NB requests must be generated to 
complete the cache line. The initial NB request that is generated by LT must set 
the CACHE bit to I and also set the ICACHE/! DC ACHE bit to 1. These bits will be 
used by CC to generate the NB request necessary to complete the ICACHE line. 

When each requests NB data returns, UU will generate a 'psuedo-op' (SN128WrtI) 
that load will from NB and stores to the IBUF (an NB request). This job's access 
type will use an access type that disables exception reporting. UU must also 
generate a control signal that will force LT to convert the address (cache 
index?,ifp?) into the appropriate IBUF physical address. NB must guarantee that 
the store request will be accepted. Otherwise the store data will be lost. 

The IBUF write control logic (gt/gtsnake) will generate a signal that indicates 
IBUF write & pbb<CACHE>=l . This will be used by CC to determine when the last 
octlet has been written which will trigger the write of the ITAG. This will also 
signal IFE that the appropriate cylinder can continue execution. 

Load/Store conflict detection must be performed to guarantee correct SRAM 
operation. This will be done adding a comparator in CJ that compares the read 
and write addresses. The controls from gt/gtsnake will be used to validate the 
compare result When a conflict is detected, the IFE will be notified. IFE will 
ignore the data and re-fetch the line that got the conflict. 

Actions: 

woody: 
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1. add a block to generate the ciMiss and perform itag protection checking. 
Mostly Done. I just have to add protection information and put in euterpe.V. 
Probably tomorrow. Although this identified some additional missing logic in 
ife. I have started looking into this logic a couple of times, but other things 
have take precedence. 

2. add ctioi and new block to euterpe.V 
Done as you know 

3. add necessary logic to LT to 'generate' IBUF physical address. 

I have chosen to wait to do this until mark has thought some about his end. 

4. modify LT, if needed, to perform translation and exception checking/reporting 
for access type = NRMLEX. 

I think this is done. I need to verify. 

5. modify LT to perform translation and exception checking/no reporting for 
access type == TRGTEX. 

Mostly in what I checked in as part of the AT change that led to BOM 134.0 

6. modify LT to set nbcin CACHE and ICACHE/IDCACHE bits. 

7. modify GTsnake logic to send notification that I-cache write completed. This 
is sent to CC to trigger the I-cache tag write. 

This will need to change now that cp is controlling the cache write. 

8. Add load/store conflict detection logic to CJ. 
no progress. 

billz: 

bill took this stuff into account when re-designing CC. 

1 . modify CC to generate NB requests for I-cache misses. 

2. modify CC to write I-cache tag. 

3. modify CC to notify IFE that I-cache tag has been written. 

4. modify NB to guarantee that IBUF store request will capture an NB entry. 

mws: 

I do not think mark has done much of this. Some may have come for free in the 
dcache changes but I do not know. 

1 . modify IFE to stop fetching (only appropriate cylinder) following a cache 
miss. Signal from CC will re-enable instruction fetching. 

2. modify UU to add BFetch instruction for initiating the NB requests 
for the I-cache miss. 

3. modify UU to add SN128WrtI instruction to receive NB data and send controls 
to LT to generate an IBUF store NB request. 

4. modify UU to support I-fetch tag and GTLB exceptions. 
I think this might have been included with exceptions 

5. modify IFE to re-fetch line when CJ detects a load/store conflict. 


What's your understanding of how far down this list we currently are? 
Tim 
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From: 


tbr 


Sent: 
To: 

Subject: 


Monday, October 03, 1994 11:30 PM 
'dickson'; 'vo' 


csyn error 


Follow Up Flag: Follow up 
Flag Status: Red 

Here's another one from BOM 134.0: 


error (DiffInputNodeSwingCheck.659) in file "tbr_euterpe-pas si. spivs": drivers are non-diff or fail teaf-inp swing 
requirements 

error (DifflnputNodeSwingCheck.657) in file "tbr_euterpe-pass 1 . spivs": drivers are non-diff or fail leaf-inp swing 
requirements 

Reason: drivers are non-differential or fail swing requirements, 
diff inputs 

instance path: top.xpadsup283.x8p_l .enadOph 

instance path: top.xpadsup283.x8p_l .en_and0ph 

cellname path: top.ttle2teu .ttle2c.in_ad0ph 

cellname path: top,ttle2teu .ttle2c.in_and0ph 
paired drivers 

instance path: top.xcerbhighOxehigh_0 

instance path: top.xcerblow0.celow_0 

cellname path: top.ceinvxS .nq_am 

cellname path: top.ceinvxS .nq_am 
paired topmost nets 

instance path: top.cehigh O 

instance path : top . ce low_0 

cellname path: top.cehighj) 

cellname path: top.celow_0 
** failed DifflnputNodeSwingCheck 
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From: Richard Dickson [dickson@staypuft] 
Sent: Monday, October 03, 1 994 1 1 :49 PM 
To: 'tbr@staypuft' 
Subject: csyn error 

tim, 

error (DifTInputNodeSwingCheck,657) in file "tbr_euterpe-pass 1 . spivs": drivers 
are non-diff or fail leaf-inp swing requirements 

Reason: drivers are non -differential or fail swing requirements, 
diff inputs 

instance path: top.xpadsup283.x8p l .en adOph 

instance path: top.xpadsup283.x8p_l .en_andOph 

eel lname path: top.ttle2teu .ttle2c.in_ad0ph 

eel lname path: top.ttle2teu .ttle2c.in_and0ph 
paired drivers 

instance path: top.xcerbhigh0.cehigh_0 

instance path: top.xcerblow0.celow_0 

eel lname path: topxeinvx5 .nq_am 

eel lname path: top.ceinvx5 .nq_am 
paired topmost nets 

instance path: top.cehigh O 

instance path: top.celow_0 

cellname path: top.cehigh_0 

cellname path: top.celow_0 
** failed DifflnputNodeSwingCheck 

i've got a cmos logic 1 and logic 0 tied to the eel diff enable 
on the pad driver that drives the cerberus clock out. 
i need to hook up a c01_l pu/pd to this enable, should i put 
an individual c01_l in the toplevel verilog (euterpe.V) 
to drive these signals ? 

dickson 
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From: tbr 

Sent: Monday, October 03, 1994 11:52 PM 

To: Tom Laidig' 

Subject: Re: disk space 

Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Sat Sep 17): 

Tim B. Robinson writes: 
I 

jHas the new partiton been allocated for building stuff under 
|/u/chip/euterpe? I want to build a lot of stuff over the weekend. 

Damn, I spaced that out yesterday! 

While you were away we completely filled the new partition! Now have s40 as well as 
s37. 

Tim 
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From: 


tbr 


To: 


Sent: 


Monday, October 03, 1994 11:57 PM 
"Richard Dickson* 


Subject: csyn error 

Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Mon Oct 3): 


tim, 


error (DifflnputNodeSwingCheck.657) in file "tbr_euterpe-passl .spivs": drivers 
are non-diff or fail leaf-inp swing requirements 

Reason: drivers are non-differential or fail swing requirements, 
diff inputs 

instance path: top.xpadsup283.x8p l .en_adOph 

instance path: top.xpadsup283.x8p_I .en_andOph 

cellname path: top.ttle2teu .ttle2c.in_ad0ph 

cellname path: top.ttIe2teu .ttle2c.in_and0ph 
paired drivers 

instance path: top.xcerbhigh0.cehigh__0 

instance path: top.xcerblow0.celow_0 

cellname path: topxeinvxS .nq_am 

cellname path: top.ceinvx5 ,nq_am 
paired topmost nets 

instance path: top.cehighj) 

instance path: top.celow 0 

cellname path: top.cehighj) 

cellname path: top.celow_0 
** failed DifElnputNodeSwingCheck 

i've got a cmos logic 1 and logic 0 tied to the eel diff enable 
on the pad driver that drives the cerberus clock out. 
i need to hook up a cOl 1 pu/pd to this enable, should i put 
an individual cOl l in the toplevel verilog (euterpe.V) 
to drive these signals ? 

Vo already has a couple inside euterpe_j>ads.V which he has specially 
placed somewhere. Can you share those or add another one there? I'd 
prefer not to have on at the top of euterpe.V 


Tim 
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From: Jay Tomlinson [woody@demeter] 
Sent: Monday, October 03, 1994 11:59 PM 
To: 'Derek Iverson' 
Cc: 'tom@demeter'; 'tbr@demeter* 
Subject: Re: cvs check-in msgs 

Derek Iverson wrote (on Fri Sep 16): 
Jay Tomlinson writes: 

> We also need to make hestia build dependant upon morphues like 

> euterpe/proteus. 

Sure. Identify all the directories that can not have compatible 
builds running in them and I will add them to the chipq.cf file. 

Here are some example proteus ones.... 

incompat proteus/dcell 
proteus/baseplate 
proteus/gards 
proteus/clockbias 
proteus/compass/layouts 
proteus/ged/sc; 


doi 

Well I finally got around to doing this. 

thanks, 
jay 

# for compiling netlists 
incompat hestia/ged 

hestia/verilog 

morpheus/gyg 

morpheus/ged 

morpheus/verilog 


# for packaging pcad parts 
incompat morpheus/gyg 
morpheu s/pcad/pd f 


Exhibit C7 


Page 69 of 703 


Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Tuesday, October 04, 1994 12:53 AM 
'hestia@aphrodite' 

'tbe@aphrodite'; 'philip@aphrodite'; 'noel@aphrodite'; 'jt@aphrodite'; 'wkm@aphrodite'; 

'yves@aphrodite' 

Netlist meeting notes 


There were a number of UL related issues on the AC/DC board covered. 

1. The relay needs to meet the UL14 92 TV5 specification. It was thought the current part 
does not meet this and that a part which does could be larger than the one currently 
specified. 

Action: tbe to check in noel 1 s absense. 

(Note: it appears from email noel posted before leaving that the new part number is for a 
relay that does meet this spec.) 


2. We need to get the UL layout requirements (trace spacing, clearance requirements etc) 
clearly documented in our design rules, or at least include a reference to the relevant UL 
documents . This will avoid a repeat of some of the mistakes made on the first rev of this 
board . 

Action: jt to get philip to handle this on his return and to ensure glen has copies of 
all relevant documentation. 


3 . The replacement rectifier identified to solve the thermal problemappears to be a long 
lead time item. However, wkm has found a supplier with enough stock to cover the 
prototype build. It was decided we should go with this part and purchase the available 
stock for the prototype build. We should investigate second sources to meet volume 
requirements . 

Action: wkm to purchase these parts for prototype build and investigate second sources, 
yves to build . gyg file and amend schematic, 
tbe to revise mechanical criteria to accommodate this part, 
glen to revise pcb layout. 


4. The hold up time issue (which has been discussed in email) is thought to still be a 
problem unless we are willing to at least double the capacity of the main reservoir 
capacitors. This is unlikely to be possible without a significant increase in physical 
size. We will continue with the current design and further investigation needs to be doen 
when noel returns. 

Action: noel to clarify anticipated performance of existing circuit and recommend changes 
for future revision if required. 


On the main board we have been able to read in the ECO at last . 

Next urgent issue is the revision of the mechanical criteria to change connector positions 
and move the screening barriers in the casting, 
tbe is working this as a high priority item. 

tbr noted a discrepancy between the implementation and software expectations in the area 
of the IR output. See mail to hestia/calliope for a discussion on this. 

The via pattern in the power pads beneath euterpe and calliope was discussed. The size is 
to be lOmil drill so they will end up solder plugged. The optimum number needs to be 
determeined based on current capacity and reliability. The number of vias required under 
the outer spacer rings also needs to be defined. General feeling was one every 100 mils 
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is fine and exact placement is not critical. It was decided we should get a better feel 
for the routing before trying to decide exact locations. 

Tim 
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From: Tom Laidig [tom@clio] 

Sent: Tuesday, October 04, 1994 7:45 AM 

To: Tim B. Robinson' 

Subject: Re: disk space 

Tim B. Robinson writes: 

|Tom Laidig wrote (on Sat Sep 17): 

j Tim B. Robinson writes: 

I I 

| | Has the new partiton been allocated for building stuff under 

| |/u/chip/euterpe? I want to build a lot of stuff over the weekend. 

j Damn, I spaced that out yesterday! 

|While you were away we completely filled the new partition! Now have s40 
jas well as s37. 

Yeah, so I gathered. I've added this to the list of areas I run du on 
every night. 

Tom L 
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From: Mark Hofmann [hopper@boreas] 
Sent: Tuesday, October 04, 1 994 8:33 AM 
To: Tim B. Robinson' 
Subject: Re: another nit 

Tim B. Robinson writes: 
If I ask loads to run on a non-existant file: 

tbr@rhodan ~/euterpe/verilog/bsrc/hc/gards 423 % loads hc-passl.edif 
egrep: hc-passl.edif: No such file or directory 
Cleaning crud from Edif file hc-passl .edif... 
/u/chip/tools/bin/hnf: bad arg to -topcell option 

Okay. I noticed the shell script on this one was less than usual 
standards [;-)!■ HI clean up. 

-hopper 
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From: John Campbell [solo@echidna] 

Sent: Tuesday, October 04, 1 994 9: 1 6 AM 

To: 'Geert Rosseel' 

Cc: 'bilKgarnbiorix'; 'bpw@ambiorix'; 'geerti^ambiorix'; 'ong@ambiorix'; 'solo@ambiorix'; 

'stid^ambiorix'; 'wingard^ambiorix* 
Subject: Re: CMOS design meeting .. 


as Geert Rosseel was saying 


Since the Xilinx project is goiing to be on hold, the next big . .project is the design 
of a CMOS design methodology / library. Think ..of it as designing a CMOS euterpe. 

Let's meet tomorrow Tuesday at 2:00 p.m. to start this project ... 

Tuesday 2:00 p.m. Hardware Conference Room .. 

Geetr 


I know Geert is tough to pronounce but at least you could try to spell it correctly. :-) 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-810 0 fax 4 08 734-8136 
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From: Jay Tomlinson [woody@melpomene] 
Sent: Tuesday, October 04, 1 994 9:16 AM 
To: 'Bill Zuravleff 
Cc: 'Jeff Marr*; Tim B. Robinson' 
Subject: Help please! dcacheeasy 

I breifly looked at dcacheeasy. dump and noticed that the CEdsbltlb_abm is set, 
disabling the memory management. I will re-run it in my area and see what 
happens. 
Jay 

Bill Zuravleff wrote (on Mon Oct 3): 
Jay, 

I need your help! I'm working on the test dcacheeasy from BOM 
134.0. 

Basically this test does three loads from cache locations 
0,0x08 and 0x10 which, according to the GTLB is backed by 
DRAM. 

In directory -billz/euterpe/verilog/bsrc there are many dump/log 
files dcacheeasy. {log,memlog,levellog, dump} and dcacheeasy.notran{}. 
The "notran" tests have translation disabled, the others have it 
enabled (via forcing the CEdsbltlb signal). 

In both cases, the loads from cache — that is loads from 
locations 0,0x8,0x10 turn into non-blocking loads. This is what I 
expect when translation is off. When translation is on, the 
gtlb entry protection field is 0x01 10000000000000 which indicates 
? uncached physical ??? Hmm. I'm a little lost here. Possibly 
1 can get together with you and jeflrn Tue morning to figure out what 
protection should be and get your help in tracing protection in the 
log file. 

Or you can peruse the log,dump,levellog,memlog files if you 
care. 

Thanks, 
billz 
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From: 


tbr 


To: 


Sent: 


Tuesday, October 04, 1994 1:43 PM 
'Mark Hofmann' 


Subject: 


Re: another nit 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofrnann wrote (on Tue Oct 4): 
Tim B. Robinson writes: 
If I ask loads to run on a non-existant file: 

tbr@rhodan ~/euterpe/verilo^src/hc/gards 423 % loads hc-passl .edif 
egrep: hc-passl .edif: No such file or directory 
Cleaning crud from Edif file hc-passl. edif... 
/u/chip/tools/bin/hnf: bad arg to -topcell option 

Okay. I noticed the shell script on this one was less than usual 
standards [ ;-) ]. I'll clean up. 


Thanks 
Tim 
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From: Jeff Marr [jeffm@kephalos] 

Sent: Tuesday, October 04, 1994 5:56 PM 

To: 'euterpe@kephalos'; 'abbot@kephalos'; 'tbr@kephalos' 

Subject: Outstanding mediacomm questions. 

The ArchQuestions posed by the MediaComm group have been gathering electron dust for a few 
months. Since we have "recently" been running into differences in assumptions about what 
is actually going to be, or already has been, implemented, I have excised some outstanding 
questions from the list, that still seem to be hot. 

These are items that I believe need statused or are still issues. 
I have tried to answer some of them. 

>EP: Instruction side: 

> Virtually (GVA) tagged 

> Upper 52 to 54 bits tag (depends on configuration 4, 8, 16K) 

> Lower 8 bit protection, rest reserved 

> 1: cache control (coherent or not) 

> 1: detail access 

> 1: access detail 

> 3 : coherence state 

> 2 : execution priv 

> -> What does it mean to have a "reserved" bit, What happens when 

> one of them is read/written? Need to finalize lower 8 bits. 

=> What's the difference between "detail access" and "access detail" 

> (typo?) . Need to define the "protection granularity register"/ its 

> exact semantics and the whole ibuffer protection mechanism, 
including 

> any interference with normal execution ("stealing of GTLB 
cycles" ) . 

Ans: Reserved is not a term used in the tags. Some bits are unused - they can be written 
and read but have no impact on execution. Still other bits, such as dtag[63:48] are 
unimplemented - they always read 0. 

Ans: The format of the protection field is: 

1 : CC 
1: da 

1: ao (unused) 

3: cs (unsused) 
2 : execution priv 

> o How do we know when a translation is usable after writing the TLBs? 

Still a bit of an issue to me. Since gltb writes go through NB, we have to 

force a dependency after a gtlb write, to make sure we do not try to use the gtlb entry 
before it is actually written. Is this OK? 

> o What is the Start Vector Addreess and how do we change to choose 
between 

ROM and Cerberus for booting? 

Is this still an issue? I think we need a FINAL DECISION posting on this 
one. 

Mediacom and Verification are fine with it either way. 

> => So are there any don f t care addresses in Hermes? 
Ans: See addr_f ormat ,mif in calliope/doc. 
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> => Assuming that the I-buffer is partitioned so that some part of it 
is 

> the I-cache, BUT all valid GTLB's have (and have had since the 
last 

> reset) the un- cached attribute on; can we put code in the cache 
part 

> of the buffer and execute it from there? (this would be useful for 

> booting) . 

I would presume that this would work. Can we get a final answer? 


> o Are all unaligned loads going to cause an exception or just some 
(which) ? 

Ans: All unaligned loads cause an alignment exception. Is there still any 
debate? 


> o Can a gateway be accessed non-blocking? 
Ans: Yes, right? 


> o What * exactly* happens on cache (both i and d) misses, timing-wise? 

> (When does the line become invalid? *How* does it become invalid? 
(tag 

> change, valid bit?) What happens if a different cylinder 
subsequently 

> misses on the same line before it becomes invalid? After it becomes 

> invalid?) 

>EP: Details not yet known. Only 1 miss is processed at a time. Missing 

> thread stalls till resolved. If second thread misses (on any line) 
it 

> will stall till first miss is resolved. Line is unavailable (to all 

> cylinders from time of first miss to when it's fully re-written. 

> => Further details? 

Needs statused. 


> o What are the latencies to various on-chip things: buffer, directly 

> accessing the cache, reading/ writing tlbs, event registers, etc. 

>EP: 2 major cycle latency to buffer/cache. event register and timers may 

> be 1 longer. TLB, tags, indirect cache much slower. Accessed via 

> physical memory bus after translation. Some serialization will be 

> performed to minimize data paths. 

> => Further details, actual numbers? What is "indirect cache"? 

Need some (ave, best, worst case) numbers for slow paths. 
Jack asked that we put this in the uarch spec, too. 


> o How can we cause an exception from an external Cerberus device? 
>EP: We agreed to somehow do this. 

> => Details? 

Ans: This is done thru Cerbuerus Register 6, bit 61. Sets bit one in the 
events pending register. 

> o Can the frequency of the Cerberus clock provided by Euterpe by 
changed? 

> How? Can it be disabled? 

Needs Statused. Very important for BU and Mfg. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, October 04, 1994 7:31 PM 
'software-checkins-dist' 
gnu-tools/sim/terp cycles, h 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/hyperion/root/sl/lisa/gnu- tools/sim/terp 

Modified Files: 
cycles .h 
Log Message: 

Use CYCLE S_TO_MINOR macro rather than doing it by hand. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, October 04, 1994 7:36 PM 
'software-checkins-dist' 
gnu-tools/sim/terp terp.h events. c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/hyperion/root/sl/lisa/gnu- tools/sim/terp 

Modified Files: 

terp.h events. c 
Log Message: 

Clean-up in cycle macros and wordy- definition of E_LVA_NE_PA. 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Wednesday, October 05, 1994 11:32 AM 

To: 'Richard Dickson' 

Cc: 'tbr@nosferatu' 

Subject: cerberus bug 

Richard Dickson wrote (on Tue Oct 4): 
lisa, 

i just checked in a change, you're 
making me nervous the bugs been there since march 10 : ) 

dickson 

Okay no excuses, but here is a stab at an explanation. 

I haven't been matching the knob registers values exactly on write 
then read. 

I had checked using the external master 

1. the individual knob registers defaults read correctly 

2. the defer write mechanism worked 

Since the design was copied from Calliope I decided to check the 
write/read of the knobs and the defer- write/clear/read of the knob 
registers via the internal master. Hence tripping over this now. 

Am I correct that the problem was introduced on March 1 0th during 
database merge from the calliope stuff to the euterpe stuff 
and since at that time both Octlet 24 and 26 were only 56 bit 
registers that also propagated to euterpe. 

There is no doubt that if I had done the same external master testing 
as I had done on Calliope I would have found it earlier. 

Sorry. 
Lisa R. 
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From: 


tbr 


To: 


Sent: 


Cc: 


Wednesday, October 05, 1994 1:00 PM 
two' 

W; 'geert'; 'hopper 1 


Subject: 


csyn 


Follow Up Flag: Follow up 
Flag Status: Red 

We found another hole. If I understand correctly, csyn does not 
insist on correct pin name qualifers at the top level, but if present 
it does check them against what it finds inside. As I recall this is 
a concious choice so that we could run csyn against significant chunks 
of a design without having to carry the baggage of fully qualified 
names around in the verilog, particularly on nodes where topt may 
later decide to re-assign swings, for example. 

Anyway, the exposure we now have and which we just tripped over 
beacuse of top level LVS erorrs, is that a whole bunch of pads on 
euterpe do not have qualifiers in the names. As a result I think 
checks are being suppressed. We need to fix the pin names (and are 
doing so), but I think we also need csyn to be able to flag errors 
where they are missing so there is no possibility for an error to slip 
through because we forgot to put qualifiers on a pin which would have 
indicated an error had they been there. 

I would suggest that this requirement be enforced unless we give a 
command line option to override it (which could be used on subblocks 
where we know later full chip runs will fully check the block 
interfaces. 


Tim 
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Sent: 
To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 05, 1994 1:00 PM 
'fwo@aphrodite' 

Vo@aphrodite'; , geert@aphrodite'; 'hopper@aphrodite' 
csyn 


We found another hole. If I understand correctly, csyn does not insist on correct pin 
name qualifers at the top level, but if present it does check them against what it finds 
inside. As I recall this is a concious choice so that we could run csyn against 
significant chunks of a design without having to carry the baggage of fully qualified 
names around in the verilog, particularly on nodes where topt may later decide to re- 
assign swings, for example. 

Anyway, the exposure we now have and which we just tripped over beacuse of top level LVS 
erorrs, is that a whole bunch of pads on euterpe do not have qualifiers in the names. As 
a result I think checks are being suppressed. We need to fix the pin names (and are doing 
so) , but I think we also need csyn to be able to flag errors where they are missing so 
there is no possibility for an error to slip through because we forgot to put qualifiers 
on a pin which would have indicated an error had they been there. 

I would suggest that this requirement be enforced unless we give a command line option to 
override it (which could be used on subblocks where we know later full chip runs will 
fully check the block interfaces. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 05, 1994 1:30 PM 
'euterpe@aphrodite'; 'craig@aphrodite' 
Shift overflows 


This note is to clarify that we have not implemented the overflow exceptions on shift 
operations. We do not have spare atoms in the data path. My understanding is that this 
has zero impact on the set top application. 


The affected opcodes are 

ESHLO, ESHLUO (behave the same as ESHL) 
ESHLIO, ESHLUIO (behave the same as ESHLI) 


Tim 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 05, 1994 1:46 PM 
'softwa re-checkins-dist' 
gnu-tools/sim/terp/calliope cable-in.c 


Update of /p/cvsroot/gnu- tools/sim/terp/calliope 
In directory 

calliope : /N/auspex/ root/s6/lisa/src/gnu-tools/sim/terp/calliope 

Modified Files: 

cable- in. c 
Log Message: 

Removed parameter EQ_lN_WORD, no longer needed by dspMakeAdaptive_cil6 ( ) . 
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To: 


Cc: 


From; 


Sent: 


Subject: 


tbr 

Wednesday, October 05, 1994 1:53 PM 

'dickson'; 'mws'; 'woody' 

'craig* 

start vector address 


Follow Up Flag: Follow up 
Flag Status: Red 


There has been some debate about how we bring up the prototypes and 
how we get flash roms initially programmed for production. Craig 
wants the start vector to be a function of the Cerberus address of 
euterpe. This would allow Euterpe to start fetching from the local 
flash interface if it's Cerberus address is 0, and from some specified 
Cerberus address if it is not zero. 

So, what I think has to be done is that rich has to add an output from 
cerberus to indicate the address is programmed to 0, then the start 
vector is CO, or CI (tbd) depending on whether this bit is 0 or 1 . 
Since I think we already have the start vecor hard wired a s a 
constant to a mux input, I think this only costs us a single cmos to ECL 
converter to drive any bits which differ between CI and C2. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 05, 1994 1:53 PM 
'dickson@aphrodite'; 'mws@aphrodite'; 'woody ©aphrodite' 
'craig@aphrodjte' 
start vector address 


There has been some debate about how we bring up the prototypes and how we get flash roms 
initially programmed for production. Craig wants the start vector to be a function of the 
Cerberus address of euterpe . This would allow Euterpe to start fetching from the local 
flash interface if it's Cerberus address is 0, and from some specified Cerberus address if 
it is not zero. 

So, what I think has to be done is that rich has to add an output from cerberus to 
indicate the address is programmed to 0, then the start vector is CO, or CI (tbd) 
depending on whether this bit is 0 or 1. 

Since I think we already have the start vecor hard wired a s a constant to a mux input, I 
think this only costs us a single cmos to ECL converter to drive any bits which differ 
between CI and C2 . 


Tim 
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From: 
Sent: 


tbr 


To: 


Cc: 


Subject: 


Wednesday, October 05, 1994 2:00 PM 
'tbe'; 'wayne' 

'gmo'; 'woody'; 'craig'; 'abbott' 
Euterpe bring up 


Follow Up Flag: Follow up 
Flag Status: Red 

Craig has clarified what he wants in Euterpe to switch start vector 
addresses for bring up. If the Euterpe Cerberus address is 0 it will 
fetch from Flash rom, if non zero it will fetch from Cerberus. 
This gives us a way to start with a completely blank flash rom on the 
board. 

Currently on the PCB we have the Cerberus address strapped to 0. 
For bring up we can easily "blue wire" this to some other value. 
However, if we intend in production to download the initial flash 
contents via Cerberus, then we would want some sort of jumper on the 
PCB to allow the address to be changed. 1 would expect this to be 
such that the jumper would be in place for downloding, and removed 
before final test/shipping. 

Do you have any preferences for what theis "jumper" should be? 

I think we should also be concerened about the security implications 
of being able to change the start vector this way. In the final 
version of hte product the flash ROM and Euterpe are supposed t be in 
the tamper-proof region to prevent the secure boot code from being 
intercepeted. We would need to make sure that this jumper position is 
similarly protected. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 05, 1994 2:00 PM 
'tbe@aphrodite'; •wayne@aphrodite* 

'gmo@aphrodite'; 'woody@aphrodite'; 'craig@aphrodite'; 'abbott@aphrodite' 
Euterpe bring up 


Craig has clarified what he wants in Euterpe to switch start vector addresses for bring 
up. If the Euterpe Cerberus address is 0 it will fetch from Flash rotti, if non zero it 
will fetch from Cerberus. 

This gives us a way to start with a completely blank flash rom on the board. 

Currently on the PCB we have the Cerberus address strapped to 0. 
For bring up we can easily "blue wire" this to some other value. 

However, if we intend in production to download the initial flash contents via Cerberus, 
then we would want some sort of jumper on the PCB to allow the address to be changed. I 
would expect this to be such that the jumper would be in place for downloding, and removed 
before final test/shipping. 

Do you have any preferences for what the is "jumper" should be? 

I think we should also be concerened about the security implications of being able to 
change the start vector this way. In the final version of hte product the flash ROM and 
Euterpe are supposed t be in the tamper -proof region to prevent the secure boot code from 
being intercepeted. We would need to make sure that this jumper position is similarly 
protected. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhodan] 
Wednesday, October 05, 1994 2:05 PM 
'geert@rhodan' 

output of euterpe/verilog/bsrc/io/.checkoutrc 


The output from euterpe/verilog/bsrc/io/ . checkoutrc is 136k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . rhodan. 4791 . euterpe-verilog-bsrc-io 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 2. 
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From: Buffalo Chip [chip@rhodan] 

Sent: Wednesday, October 05, 1 994 2: 1 5 PM 

To: 'geert@rhodan' 

Subject: output of euterpe/verilog/bsrc/io/.checkoutrc 


Wed Oct 5 12:06:06 PDT 1994 (geert Wed, 5 Oct 1994 11:38:51 -0700) 
euterpe/verilog/bsrc/io 

[Release BOM (V20.0) in euterpe/verilog/bsrc/io (Wed Oct 5 12:06:07 PDT 1994)] 


Dir euterpe/verilog/bsrc/io BOM 20.0 

9.5 . checkout rc 

1.12 Makefile 

9.5 clean-request 

8.1 genpim0.pl 

8.4 genpiml.pl 

7.5 io_control .pirn 

8 . 3 io_control_2 . pim 

6.2 io_ififo.V 

6 . 1 io_iphase . Veqn 

6.1 io_ofifo.V 

6 . 1 io_ophase . Veqn 

6.2 io_sciof f_6 . V 
6.1 io_sciof f_9 . V 

3.1 iocount.pla 

3.2 iodrive.V 

3.1 iofs.Veqn 

3.5 iorate.V 

3 . 4 iosync . V 

4.6 pimlib.pl 

7 . 2 power . tab . local 


===> running euterpe/verilog/bsrc/io/ . checkoutrc (Wed Oct 5 12:06:16 PDT 
1994) <=== 

gmake: "clean 1 is up to date. 
# 

# turn off pgroute 
# 

[ -f gards / nop g route ] j | touch gards/nopgroute # # use padtiles # [ -f gards/usepadtiles 

] | | touch gards/usepadtiles # # use pifpack # [ -f gards/usepifpack ] | | touch 

gards /usepif pack # # insert an instance of the clock tree # [ -f gards /addclock ] | J touch 

gards /addc lock # # disable old dcell placement obstruction # [ -f gards/noobs ] | j touch 

gards /noobs # # now do it . . . 

# 

gmake GARDS_DISPLAY=clio: 0 . 0 gards/ ioO- iter 
gmake [1]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/io' 
# 

# Get an initial sdl file. A manhattan approximation will be used # gmake 
GARDS_DISPLAY=clio: 0 . 0 CYCLETIME=895 gards/io0-pass2 . sdl 

gmake [2]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/io ' 
gmake [2] : "gards/io0-pass2 . sdl ' is up to date, 
gmake [2] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/io ' 
ft 

# Now route it - can't ask for this directly because gplace rule would be # needed twice, 
gmake forbids this # gmake GARDS_DISPLAY=clio : 0 . 0 CYCLETIME=895 gards/ ioO -pass2 . garout . lis 
gmake [2]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/io 1 

**** GPLACE io0-pass2 

Wed Oct 5 12:06:48 PDT 1994 

sed -e ' s IDES IGN_NAME ! ioO -pas s2 i 1 -e "s !EDIF_FILE ! io0-pass2 . sdl J " \ 

-e 1 s ICHIPROOT! /n/auspex/sl0 /chip/euterpe ! ' -e • s ! TECH_GPLACE J ioO - 
pass2 . gplace .mobi234 ! '\ 
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-e ' S !TECH_REDIT!ioO-pass2 .redit .mobi234 ! ' \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/ ioO -pass2 . vrf rm -f 
gards/io0-pass2 .gplace.nic cd gards; if HOME=/n/auspex/slO/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/license/license.dat 
DISPLAY=clio: 0. 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -p -s io0-pass2; then \ 

/usr/5bin/echo 'deletegroup use; ok' > io0-pass2 .gplace .nic; f i 
/usr/5bin/echo 'readpif io0-pass2 .pif ; ok' >> 
gards/io0-pass2 . gplace .nic 

/usr/5bin/echo 'makeauto use; ok' >> 
gards/io0-pass2 .gplace.nic 

/usr/5bin/echo 1 iparam sweeps 0;' >> 
gards/io0-pass2 . gplace .nic 

/usr/5bin/echo 'iparam algorithm hper_net length ; ' >> 
gards/ioO -pass2 . gplace . nic 

/usr/5bin/echo 'improve use; ok' » 
gards/io0-pass2 .gplace . nic 

/usr/5bin/echo 'writenof io0-pass2 .nof ; use; ok' >> 
gards/io0-pass2 .gplace . nic 

/usr/5bin/echo ' exit save \nex it no save ' » 
gards/io0-pass2 .gplace.nic 
(echo "cd "abspath" /gards ; \ 

HOME=/n/auspex/sl0/chip/euterpe/ tools 
LM_LICENSE_FlLE==/n/auspex/slO/chip/euterpe/tools/sl/license/ license.dat 
DISPLAY= clio: 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke gplace io0-pass2 -listing ioO- 
pass2 . gplace . lis -cmdin io0-pass2 . gplace .nic -colorin 
io0-pass2 .gplace. mobi234 -inbat 1" | \ 
/usr/local/bin/rexec rhodan sh && 
HOME=/n/auspex/sl0/chip/euterpe/ tools 

LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/ tools /si/ license/license . dat 
DISPLAY=clio : 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -sp gards/io0-pass2 ) | | (mv gards/ioO- 
pass2 .gplace . lis gards/io0-pass2 . gplace . lis . ERROR; rm -f io0-pass2 . nof ; false) 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS GPLACE 7.126 -- General Placer 

Copyright (c) 1994 SILVAR-LISCO . All rights reserved. 
Design: io0-pass2 Started at: 94/10/05 12:06:57 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components. . . 

Loading nets. . . 

Loading logical types... 

Processing physical types. . . 

Loading cell_types. . . 

Creating net-comp xref table... 


Terminated at : 94/10/05 12:10:29 

Elapsed CPU time : 0 Hrs 2 Mins 32 Sees 

Elapsed wall clock time : 0 Hrs 3 Mins 32 Sees 
gmake[2]: *** [gards/ioO -pass2 . gplace . lis] Error 1 
gmake[2] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/io 1 
gmake[l]: *** [ioO -base . short . nets] Error 1 
gmake[l]: Leaving directory 

- /N/auspex/root/slO/chip/euterpe/verilog/bsrc/io ' 

gmake: *** [ioOgards] Error 1 

# 
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# turn off pgroute 
# 

[ -f gards/nopgroute ] j | touch gards/nopgroute # # use padtiles # [ -f gards/usepadtiles 
] | | touch gards/usepadtiles # # use pifpack # [ -f gards/usepifpack ] | | touch 
gards/usepifpack # # insert an instance of the clock tree # [ -f gards/addclock ] | | touch 
gards/addclock # # disable old dcell placement obstruction # [ -f gards/noobs ] | | touch 
gards/noobs # # now do it . . . 
# 

gmake GARDS_DISPLAY=clio : 0 . 0 gards/iol- iter 
gmake[l]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/io' 
# 

# Get an initial sdl file. A manhattan approximation will be used # gmake 
GARDS_DISPLAY=clio:0.0 CYCLETIME=895 gards/iol -pass2 . sdl 

gmake [2]: Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/io ' 
gmake [2]: *'gards/iol-pass2 . sdl ' is up to date, 
gmake [2]: Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/io 1 
# 

# Now route it - can't ask for this directly because gplace rule would be # needed twice, 
gmake forbids this # gmake GARDS_DISPLAY=clio : 0 . 0 CYCLETIME=8 95 gards/iol-pass2 . garout . lis 
gmake [2]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/io' 

**** GPLACE iol-pass2 

Wed Oct 5 12:10:58 PDT 1994 

sed -e 1 s !DESIGN_NAME!iol-pass2 ! ' -e "s!EDIF_FILE!iol-pass2.sdl! " \ 

-e ■ s!CHIPROOT!/n/auspex/sl0/chip/euterpe! ' -e ' s ! TECH_GPLACE ! iol - 

pass2 . gplace .mobi23 4 ! 1 \ 

-e ' s !TECH_REDITi iol-pass2 .redit ,mobi234 ! ' \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/iol-pass2 . vrf rm -f 
gards/iol-pass2 .gplace .nic cd gards; if HOME=/n/auspex/sl0/chip/euterpe/ tools 
LM_LICENSE_FILE=/n/auspex/ slO/chip/euterpe/tools/sl/license/license . dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -p -s iol-pass2; then \ 

/usr/5bin/echo 1 deletegroup use; ok' > iol-pass2 . gplace .nic; fi 
/usr/5bin/echo 'readpif iol-pass2 .pif ; ok' >> 
gards/iol-pass2 . gplace .nic 

/usr/5bin/echo 'makeauto use; ok' >> 
gards/iol-pass2 .gplace .nic 

/usr/5bin/echo ' iparam sweeps 0;' » 
gards/iol-pass2 .gplace. nic 

/usr/5bin/echo 'iparam algorithm hper_netlength; • >> 
gards/iol-pass2 . gplace .nic 

/usr/5bin/echo 'improve use; ok' >> 
gards/ iol-pass2 . gplace .nic 

/usr/5bin/echo 'writenof iol-pass2 .nof ; use; ok' >> 
gards/iol-pass2 . gplace . nic 

/usr/5bin/echo ' exit save \nexitnosave ' >> 
gards/iol-pass2 . gplace .nic 
(echo "cd "abspath" /gards; \ 

HOME= / n/ auspex/s 10/ chip/ eut erpe / tools 
LM_JLICENSE_FILE=/n/auspex/slO/chip/euterpe/ tools/ si/ license/license. dat 
DISPLAY=clio:0 . 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/ invoke gplace iol-pass2 -listing iol- 
pass2 . gplace . lis -cmdin iol -pass2 . gplace . nic -colorin 
iol-pass2 . gplace .mobi2 34 -inbat 1" | \ 

/usr/local/bin/rexec rhodan sh 
HOME=/n/auspex/slO/chip/euterpe/tools 

LM__LICENSE_FILE=/n/auspex/ si 0/chip/eut erpe /tools/ si/ license/license . dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -sp gards/iol-pass2) | | (mv gards/iol- 
pass2 .gplace. lis gards /iol -pa ss2 . gplace . lis . ERROR; rm -f iol-pass2 . nof ; false) 

Requires a minimum license of xgplacel_3 or gards 1_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
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GARDS GPLACE 7.126 -- General Placer 

Copyright (c) 1994 SILVAR-LISCO. All rights reserved. 
Design: iol-pass2 Started at: 94/10/05 12:11:02 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components. . . 

Loading nets. . . 

Loading logical types . . . 

Processing physical types... 

Loading cell_types. . . 

Creating net-comp xref table... 


Terminated at : 94/10/05 12:14:39 

Elapsed CPU time : 0 Hrs 2 Mins 35 Sees 

Elapsed wall clock time : 0 Hrs 3 Mins 37 Sees 
gmake[2]: *** [gards/iol-pass2 . gplace . lis] Error 1 
gmake [2]: Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/ io' 
gmake[l]: *** [iol-base . short . nets] Error 1 
gmake [1] : Leaving directory 

" /N/auspex/root/ slO/chip/euterpe/verilog/bsrc/ io ' 
gmake: *** [iolgards] Error 1 

[finished at Wed Oct 5 12:14:43 PDT 1994 -- exit status 2] 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Wednesday, October 05, 1994 2:28 PM 
'craig@nosferatu' 

'bobm@nosferatu'; 'dickson@nosferatu'; 'tbr@nosferatu'; Vo@nosferatu' 
Cerberus codes 


Please confirm that the Euterpe Architecture, Implementor and Manufacturer codes are as 
specified in the latest version of both the Architecture and Micro-Architecture documents. 

namely: 

Cerb octlet 0: 
0040a32469930100 

Cerb octlet 1: 
0040a3d2b67f 0100 

Cerb octlet 2 : 
0040a369db3f 0100 


Lisa R. 
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From: Bob Morgan [bobm@mercury] 
Sent: Wednesday, October 05, 1994 2:44 PM 
To: 'karzes@mercui r y'; 'tbr@mercury' 
Subject: Shift overflows - muse.euterpe #1 039 

Tom, 

Does this then clarify the statement you have in the 

xlu information about ESHLO, ESHLUO, EHSLIO, and ESHLIUO 

needing support outside the xlu if implemented? 

If not, Tim, where should I document this difference 

from Terpsichore? 

Thanks, 

Bob 

In article <199410051830.LAA10336@aphrodite.microunity.com>, tbr@aphrodite.microunity.com (Tim B. Robinson) 
writes: 

l> 

|> This note is to clarify that we have not implemented the overflow 

j> exceptions on shift operations. We do not have spare atoms in the 

|> data path. My understanding is that this has zero impact on the set 

|> top application. 

I> 

l> 

|> The affected opcodes are 
l> 

|> ESHLO, ESHLUO (behave the same as ESHL) 
|> ESHLIO, ESHLUIO (behave the same as ESHLI) 

l> 

|>Tim 
l> 
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From: 


tbr 


To: 


Cc: 


Sent: 


Subject: 


Wednesday, October 05, 1994 3:46 PM 

'Bob Morgan' 

'karzes@mercury' 

Shift overflows - muse.euterpe #1039 


Follow Up Flag: Follow up 
Flag Status: Red 

Bob Morgan wrote (on Wed Oct 5): 
Tom, 

Does this then clarify the statement you have in the 

xlu information about ESHLO, ESHLUO, EHSLIO, and ESHLIUO 

needing support outside the xlu if implemented? 

If not, Tim, where should I document this difference 
from Terpsichore? 

Yes this is that same issue. We don't have room to add the additional 
stuff in the datapath outside the XLU. 


Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Wednesday, October 05, 1 994 3:48 PM 

To: 'craig@aphrodite' 

Cc: 'dickson ©aphrodite'; 'lisar^aphrodite' 

Subject: euterpe architecture definition register 


We need a final definition for octlet 4. The current architecture doc only specifies bits 
56-63. 

Tim 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Guillermo A. Loyola [gmo@microunity.com] 

Wednesday, October 05, 1994 4:32 PM 

, euterpe@gaea > 


jeffm@kephalos.microunity.com (Jeff Marr) writes: 
| > > o Can a gateway be accessed non-blocking? 

|> 

|> Ans: Yes, right? 

Wrong. The word I last got from mws is that the targets of bgates and compare -and -op 
instructions need to be in dbuffer or must be cached. 


Gmo . 
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From: Loretta Guarino [guarino@MicroUnity.com] 

Sent: Wednesday, October 05, 1994 4:44 PM 

To: 'lisa@MicroUnity.com' 

Subject: Bring-up meeting notes 


I'll include you on the cc line in the future, since Gmo thinks you may find yourself 
involved in some of this. :-) 

Loretta 


Forwarded Message 

Return- Path : <guar ino@MicroUnity . com> 

Received: from thessalus.microunity.com by gaea.microunity.com 
(4 ,1/musel. 3) 

id AA18167; Wed, 5 Oct 94 14:30:29 PDT 
Received: from [127.0.0.1] by thessalus.microunity.com ( 8 . 6 . 4/muse- sw . 2 ) 

id OAA16943; Wed, 5 Oct 1994 14:32:09 -0700 
Message-Id: <199410052132 . OAA1694 3@thessalus . microunity . com> 
To: wayne@MicroUnity.com, doi@MicroUnity.com, jeffm@MicroUnity.com, 

iimura@MicroUnity.com, grao@MicroUnity , com, sandeep@MicroUnity.com 
Cc : guarino@MicroUnity . com, lisar@MicroUnity . com, abbott@MicroUnity . com 
Subject: bring-up meeting of Oct. 5 
Date: Wed, 05 Oct 94 14:32:08-0700 
From: Loretta Guarino <guarino@MicroUnity . com> 


Next meeting: Wednesday, Oct. 12, at 10:30. 

Please let me know about any errors in my notes from today's meeting. I may have 
misunderstood, especially HW-talk. 

Action items from last week: 

Wayne : 

1. confirm with Tim that there is some way to turn 
off the Euterpe clock, so the CBI can be the master 

>> Wayne confirmed that there is no programmable divisor for the clock. 
>> He is taking the action to make sure there will be a jumper on the 
>> prototype boards to override the clock. 

2. talk with Tim about whether the start vector 
address can be set to boot from Cerberus, instead 
of hardwired to boot from ROM 

>> Tim has agreed that we need to be able to set the start vector 
» address, but the design work for 
functionality hasn't been done. 

3 . change board design for development to have a 
socket for the Flash ROM 

» Wayne explained the many problems here, including no tools for 

>> programing the package, no sockets for the package, etc. He will 

>> continue to explore possibilities, but any solution is probably going 

>> to be jury-rigged and only on a few boards. 

Sandeep and Derek: 

1. implement parallel port device drivers for sun and 
sgi 

>> No progress; depends on the parallel interface definition. 
Jeff: 

1. investigate what hardware support is needed to be 
able to run tests from different locations (e.g. 
buffer, ROM, RAM, Cerberus) 
>> Start a dialog with Wayne; in progress 
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2 . write up plan for external aspects of test control 
>> Jeff distributed his plan at today's meeting, describing 
>> requirements, the initial test control sequence, and open issues. 

Wayne and Sandeep : 

1 . develop a strategy so that the workstation can 
respond to read requests before the request times 
out 

>> Wayne talked with Craig, who said that infinite delays can be 
» inserted. So this problem is deferred to the hardware. 

Je f f , Wayne , Gmo : 

1 . develop plans for a quick and dirty 
characterization test 
>> No progress 

Gmo : 

1 . write up a plan for virtual devices and their 
interaction with gdb 

>> Gmo presented prelimary work; he divided tests into 3 categories 

» (bare test that always executed from ROM or CerbROM, standalone tests 

>> that are loaded by a bootstrap loader, and kernel tests that run on 

» the Microkernel. Gmo and Jeff need to define the boot state that is 

>> set for standalone tests. We discussed UI issues for running tests, 

>> and whether gdb provides enough support for running regression 

» scripts. Derek will provide whatever support is needed above gdb. 

2 . confirm with Tim which Cerberus bit will cause a 
Euterpe event 

>> Done: bit 61 


Wayne's test plan is located in 

/u/chip/hestia/doc/testplans/MediaComputer_Test_Plan. 
The section most relevant to our plans is the "Sys" 
chapter . 

Current Action Items : 

Make sure there is a jumper on the prototype boards to override the clock. (Wayne) 

Explore solutions for programming FlashROM from a separate fixture, that is, without 

Euterpe code . 

(Wayne) 

Define parallel interface. (Wayne, Gmo, and Sandeep) 

Implement parallel port device drivers for sun and sgi . (Sandeep and Derek) 

Investigate what hardware support is needed to run tests from different locations (e.g. 
buffer, ROM, RAM, Cerberus) . (Jeff, Wayne) 

Develop plans for a quick and dirty characterization test. (Jeff, Wayne, Gmo) 

Define the boot state for standalone tests. (Jeff, 
Gmo) 

Write up a plan for virtual devices and their interaction with gdb (Gmo) 

Build scripting/UI capabilities above gdb for regression tests. (Derek) 

Create a separate tool for loading FlashROM (CerbROM code that runs as a bare test?) 
(Who???) 


End of Forwarded Message 
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Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 05, 1 994 5:05 PM 
'gmo@microunity.com' 
'euterpe@gaea' 


Guillermo A. Loyola wrote (on Wed Oct 5) : 

jeffm@kephalos.microunity.com (Jeff Marr) writes: 
| > > o Can a gateway be accessed non-blocking? 

i> 

j> Ans: Yes, right? 

Wrong. The word I last got from raws is that the targets of bgates and 
compare -and -op instructions need to be in dbuffer or must be cached. 

Yes. We'd like to do it properly, but it adds a ton of complication to handle the unknown 
return latency. So in this edition assume the multi mem ref ops have to hit buffer or 


cache . 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Wayne Freitas [wayne ©echidna] 

Wednesday, October 05, 1994 5:56 PM 

'tbe@aphrodite'; 'wayne@aphrodite'; 'tbr@aphrodite' 

^©©aphrodite'; 'woody@aphrodite'; 'craig@aphrodite'; 'abbott@aphrodite' 

Re: Euterpe bring up 


> From tbr@aphrodite Wed Oct 5 11:59:02 1994 

> Date: Wed, 5 Oct 1994 12:00:29 -0700 

> From: tbr@aphrodite (Tim B. Robinson) 

> To: tbe@aphrodite, wayne@aphrodite 

> Cc: gmo@aphrodite, woody@aphrodite , craig@aphrodite r abbot t ©aphrodite 

> Subject: Euterpe bring up 

> Content -Length: 1144 


> Craig has clarified what he wants in Euterpe to switch start vector 

> addresses for bring up. If the Euterpe Cerberus address is 0 it will 

> fetch from Flash rotn, if non zero it will fetch from Cerberus. 

> This gives us a way to start with a completely blank flash rom on the 

> board. 
> 

> Currently on the PCB we have the Cerberus address strapped to 0 . 

> For bring up we can easily "blue wire" this to some other value. 

> However, if we intend in production to download the initial flash 

> contents via Cerberus, then we would want some sort of jumper on the 

> PCB to allow the address to be changed. I would expect this to be 

> such that the jumper would be in place for downloding, and removed 

> before final test/ shipping. 
> 

> Do you have any preferences for what theis "jumper" should be? 
> 

> I think we should also be concerened about the security implications 

> of being able to change the start vector this way. In the final 

> version of hte product the flash ROM and Euterpe are supposed t be in 

> the tamper-proof region to prevent the secure boot code from being 

> intercepeted. We would need to make sure that this jumper position is 

> similarly protected. 


For the 1st prototype boards can we just bring address 0 out to a 
Hermes expansion port somewhere next to where the Cerberus bus comes 
out. This line should have a pulldown resistor say IK or so on it that 
causes it to boot from Flash ROM if the line isn't connected. 


> 


> Tim 


> 


Wayne 
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From: 
Sent: 
To: 

Subject: 


Richard Dickson [dickson@demeter] 
Wednesday, October 05, 1994 6:30 PM 
'softheads@demeter' 
icache miss 


you ' all, 


if i cache misses were handled by an exception and software handled the icache line 
fills what would be the short comings. 

i realize one of us 'hardware weenies' in the past said it would be easy to implement a 
gate level controller for this function. 

given that it would take at least 2 00-250 minor clock cycles to fetch the data from dram 
no matter how its done would a software controlled icache add significantly to this total. 

from where i stand there are two advantages to a software only solution. 

1) fewer gates 

2) we will finish the euterpe logic design sooner 


dickson 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhodan] 
Wednesday, October 05, 1994 6:46 PM 
'geert@rhodan' 

output of euterpe/verilog/bsrc/io/.checkoutrc 


The output from euterpe/verilog/bsrc/io/ . checkoutrc is 584k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . rhodan . 11582 . euterpe-verilog-bsrc- io 

(which is accessible from all machines). This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 05, 1994 8:42 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory.h 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
memory . h 
Log Message: 

- Added some macros for checking the "magic" bits in address (47 and 15) . 

- Slightly modified hazard detection code to keep on-chip addresses from being viewed as 
conflicts with cache/nb addresses. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 05, 1 994 8:42 PM 
'software-checkins-dist' 
gnu-tools/sim/terp execloop.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/ sim/terp 

Modified Files: 

execloop . c 
Log Message: 

Minor change in macro name. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 05, 1994 8:44 PM 

'software-checkins-dist' 

gnu-tools/si m/terp vjnem.c 


Update of /p/c vsroot /gnu- tools /sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools /sim/terp 

Modified Files: 

v_mem . c 
Log Message: 

in gv_to_p() , check that va[47] == pa [47] , and that if a [47] is set, then va[15] == pa [15] 
-- if not, then exception E_LVA_NE_PA is given. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 05, 1994 8:48 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. c 


Update of /p/cvsroot /gnu- tools /sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

- If REALLY_ACCURATE_SIMULATION: 

1. Bits 48-63 of an address being accessed must be the same as those same 
bits in the base register of the ld/st. If not, then exception 
E_BASE_NE_LVA is given. 

2. Check the exception- causing dcache tag protection bits (detail, 
coherence) 

and cause appropriate exception if set. 

- Rearranged some code in data_access ( ) so that a gv-to-p translation is 
avoided if possible, and so that the sram hazard detection doesn't find 
conflicts between on-chip and cache/rib addresses. 
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From: 


tbe@microunity.com 

Wednesday, October 05, 1994 10:15 PM 

Tiestia @microu nity.com' 

'tbr@microunjty.com'; 'pmayer@microunity.com'; Vijay@m icrounity.com'; 
'woody@microunity.com'; 'jt@microunity.com'; 'ras@microunity.com' 
hermes channel expansion port routing 


Sent: 

To: 

Cc: 


Subject: 


Tbr and I conferred on the difficulties Pattie has encountered with routing the expansion 
connector. Based on this and earlier discussions with ras and Pattie, we decided that the 
EMI risk was minimal if we run the Hermes traces on the component side of the pcb out to 
the area above the expansion connector and go through vias placed in between the pad rows 
to connect to the pads on the secondary side. This requires another mod to the spacer, 
similar to the relief added between calliope and euterpe. Pattie should define the trace 
routing and that will provide Vijay with the clearance requirment for this new opening. 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 08 9 
(408)734-8100, (408)734-8136 fax 


tbe@microunity . com 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Thursday, October 06, 1994 11:10 AM 

To: 'euterpe@nosferatu' 

Subject: icache miss 


Start of forwarded message 

Status: RO 

X-VM-v5-Data : ([nil nil nil nil nil nil nil nil nil] 

["603" "Wed" "5" "October" "1994" "16:30:22" "-0700" "Richard Dickson" 
"dickson@demeter " nil "22" "icache miss" " A From:" nil nil "10"]) 
Return- Path: <dickson@demeter> 

Received: from demeter.microunity.com by gaea.microunity.com (4 . 1/musel . 3 ) 

id AA25075; Wed, 5 Oct 94 16:28:40 PDT 
Received: from localhost by demeter.microunity.com (8 . 6 . 4/muse-sw. 2 ) 

id QAA08774; Wed, 5 Oct 1994 16:30:22 -0700 
Message-Id: <199410052330 . QAA08774@demeter .microunity . com> 
From: dickson@demeter (Richard Dickson) 
To: sof theads@demeter 
Subject: icache miss 

Date: Wed, 5 Oct 1994 16:30:22 -0700 
you' all, 

if i cache misses were handled by an exception and software handled the icache line 
fills what would be the short comings. 

i realize one of us 'hardware weenies' in the past said it would be easy to implement a 
gate level controller for this function. 

given that it would take at least 200-250 minor clock cycles to fetch the data from dram 
no matter how its done would a software controlled icache add significantly to this total. 

from where i stand there are two advantages to a software only solution. 

1) fewer gates 

2) we will finish the euterpe logic design sooner 


dickson 

End of forwarded message 
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From: lisa 

Sent: Thursday, October 06, 1 994 1 2: 1 6 PM 

To: 'Jeff Marr' 

Subject: Re: gnu-tools/sim/terp vjmem.c 


> You will hate me, but E_VLA_NE_PA should be asserted iff: 
> 

> if va[47] != pa [4 7] then 

> exception 
> 

> if va [47] == 1 then 

> if va[15:6] != pa [15: 6] then 

> exception 
> 

> Or did you know this? 

No, I didn't know that. If you want me to compare all of bits 6-15, you'll have to change 
the uarch document. *Then*, I'll implement what is written there. (Sorry, but I'm in a 
bad mood this morning!) 

lisa 


Exhibit C7 


Page 113 of 7 


From: 
Sent: 
To: 


sysadm@gaea on behalf of Jeff Marr [jeffm@microunity.com] 

Thursday, October 06, 1994 12:51 PM 

'euterpe@gaea' 


> if i cache misses were handled by an exception and software handled 

> the icache line fills what would be the short comings. 
> 

> i realize one of us 'hardware weenies' in the past said it would be 

> easy to implement a gate level controller for this function. 
> 

> given that it would take at least 200-250 minor clock cycles to fetch 

> the data from dram no matter how its done would a software controlled 

> icache add significantly to this total. 

7* 

> from where i stand there are two advantages to a software only 

> solution. 
> 

> 1) fewer gates 

> 2) we will finish the euterpe logic design sooner 


> dickson 
tbr asked me to (using no capital letters) find out how many major cycles it takes to 
enter and leave an exception handler, based on a quick look at a single test, it takes 10 
major cycles to enter a handler, and 7 major cycles to leave it (counting bback as part of 
leaving) . 

there are several things that can delay entrance into the handler, and I have not 
addressed those at all. these include: outstanding NB requests and exception locks. 

jef fm 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 06, 1994 2:14 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

Oops... cache-hit code that avoided a gv-to-p translation needs to use the dcache line's 
ptag for grabbing the access structure. 
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From: 
Sent: 
To: 

Subject: 


Craig Hansen [craig@mnemosyne] 
Thursday, October 06, 1994 3:20 PM 
'craig@aphrodite'; 'euterpe@aphrodite'; 'tbr@aphrodite' 
Re: Shift overflows 


> From tbr@aphrodite Wed Oct 5 11:30:43 1994 

> Return- Path: <tbr@aphrodite> 

> Received: from aphrodite.microunity.com by mnemosyne.microunity.com 
(8 . 6 . 4/muse-sw. 2) 

> > id LAA22477; Wed, 5 Oct 1994 11:30:42 -0700 

> Received: from localhost by aphrodite.microunity.com ( 8 . 6 . 4/muse- sw. 2 ) 

> > id LAA10336; Wed, 5 Oct 1994 11:30:28 -0700 

> Date: Wed, 5 Oct 1994 11:30:28 -0700 

> From: tbr@aphrodite {Tim B. Robinson) 

> Message- Id: <19941005183 0 .LAAl03 3 6@aphrodite .microunity . com> 

> To: euterpe@aphrodite, craig@aphrodite 

> Subject: Shift overflows 

> Status: RO 


> This note is to clarify that we have not implemented the overflow 

> exceptions on shift operations. We do not have spare atoms in the 

> data path. My understanding is that this has zero impact on the set 

> top application. 


> The affected opcodes are 

> ESHLO, ESHLUO (behave the same as ESHL) ESHLIO, ESHLUIO (behave the 

> same as ESHLI) 


These overflow checks use the result computed by the ELMS and EULMS hardware to check for 
overflow. They should not require additional data path hardware. 


> Tim 


Craig 
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From: Jay Tomlinson [woody@melpomene] 
Sent: Thursday, October 06, 1994 3:22 PM 
To: , woody@melpomene'; , tbr@melpomene' 

Subject: Meeting Summary: Microachitecture 4/6/94 - muse.euterpe #785 

In article < 1994040804 56. VA AO 1042@aphrodite.microunity.com>, tbr@aphrodite.microunity.com (Tim B. Robinson) 

writes: 

l> 

|> Notes from Wednesday's meeting to resolve open micro-architecture issues 
j> 

|> The bulleted items are the "detail questions" from curtis' list of 3/29. 
|> Not all items were resolved, but in most cases actions were taken to get 
|> resolution. 
I> 

|> o What is the format and content of a cache tag? In particular, how many 
|> bits of tag are there, and what other bits (e.g. dirty) does the cache 
|> tag contain. 

I> 

|> Data side: 

l> 

|> 64 bits total 
|> upper 58 bits tag 
|> lower 6 bits protection (provisionally) 


j> 3: coherence state (software managed) 

|> 1 : detail access 

|> 1 : dirty 

|> 1 : reserved 

l> 


j> There is no valid bit; tags need to be initialized to an unused 
|> address. Craig may want to roll the functionality of the dirty 
j> bit into the coherence state. Designers would prefer to keep it 
|> separate for ease of management. 
I> 

|> Action: Craig to provide final definition of lower 6 bits. 

|> Action: Tbr to confirm with array designers we can get separate WE for 

|> the dirty bit. 

I> 

|> Instruction side: 
l> 

|> Virtually tagged 

|> Upper 52 to 54 bits tag (depends on configuration 4, 8, 16K) 
|> Lower 8 bit protection, rest reserved 


j> 1 : cache control (coherent or not) 

|> 1 : detail access 

]> 1 : access detail 

|> 3: coherence state 

|> 2: execution priv 
l> 


j> Action: Craig to provide final definition of lower 8 bits 

l> 

[> There is a problem with protection of the IB now we have doubled the 

|> throughput of the Dcache since the I side no longer has access to the GTLB. 

|> Craig proposes an architecturally defined register to set the protection 

|> granularity. Crossing a protection boundary or taking a branch causes the 

|> I side to steal a cycle from the GTLB and cache the accessed entry. 

I> 
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|> Action: Craig to define this register 

l> 

|> o What is the layout of protection information in a TLB? What is the 
|> interpretation of the cache control bits? Does it differ for local and 
|> global tlbs? Are all the fields operational, e.g., detail protection. 

I> 

|> LTLB: 

j> 

|> Mask, match, and protection always zero. A separate control 
|> bit will disable both the LTLB and GTLB at startup. 

I> 

|> Action: Craig to define this bit 
l> 

|> GTLB: 

l> 

|> 58 XOR bits, 14 protection bits 

l> 

|> Current architecture document calls for 15 protection bits. 
|> Hardware only implements 14. One bit was eliminated some months 
|> ago (tbr says from the coherence information), but we seem to 
|> have lost track of which. 

!> 

J> Action: Tbr to track down the missing bit 

l> 

|> Detail access will be supported as an exception. 
I> 

|> o What are the exceptions generated by the machine? Can TPROT, TDETAIL, 
|> and TCOHERENCE go away? To what numbers are they assigned in the event 
|> register? 

I> 

|> What does TPROT refer to? The architecture document need a complete 
|> re- write in this area. 

I> 

|> Action: Craig to re-write this section 

l> 

j> o What is the mechanism for starting, stopping, and initializing cylinders? 
|> Is there a way to query what state a cylinder is in? Stopped, running, 
|> taken exception, etc. 
I> 

|> Control register has one bit per thread to disable the thread. 

|> Machine starts up with all but the event thread disabled. Bits can be 

|> written to start/stop threads. A second bit per thread "thread has 

|> stopped" returns current status. An exception sets the bit that 

|> enables the event thread. 

I> 

|> Action: Craig to redefine the control register 
l> 

|> o Is there a register containing the current cylinder number? 
I> 

|> Current cylinder number will be available in a register 

l> 

|> Action: Craig to define where 

l> 

j> o When do we check the pc value of a cylinder after stopping it (i.e. any 

|> settling time)? 

I> 

|> Wait for the "thread has stopped" bit to be set. 
I> 

|> o What is true about address translation at reset? 
f> 

|> LVA = GVA = physical 
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I> 

|> o What is the real address map. 

I> 

|> Action: Craig to review gmo RFC 2/2/94. Probably will change relationship 
|> between Hermes and DRAM 

l> 

|> o How do the cache control bits in the TLB's interact with non-blocking 

|> loads. 

I> 

|> Non-cached == non-blocking 
|> no-allocate miss == non-blocking 
l> 

|> o What happens when a bad address is used on Cerberus? Hermes? 
i> 

|> Cerberus gets a timeout, mapped to a machine check 

|> Hermes returns an error packet, mapped to machine check 

l> 

j> o Can code be executed from the I-cache (assuming it is not being used as a 

|> cache by way of cache control bits). 

I> 

|> Code can be executed from the I cache! ! ! Can someone clarify the 

|> question please? 

I> 

|> o Can we access the ROM through the caches? Hermes devices? 

I> 

|> Yes. 

I> 

|> o What happens when a non-blocking-load is for less than an octlet? 
I> 

|> Tbr wants this to be a trap. Craig wants it to be handled in hardware 
|> and also for stores. 

I> 

|> Action: Input from software group - is it acceptable to have only octlet/hexlet 
|> load store when not in cache? 

I> 

|> o Are all unaligned loads going to cause an exception or just some (which)? 

I> 

[> Tbr wants all to cause an exception. Craig says this is not 

j> acceptable because of requirement for PC emulation. Not resolved. 

I> 

|> o Is there a difference in performance between big and little endian loads 
|> and stores? 

I> 

|> No. 

I> 

j> o What is the period of the cycle counter (minor clocks or major clocks)? 

i> 

|> Per Craig's preference - minor. 

!> 

|> o What is the actual width of the clock related registers? 

I> 

|> 32 bits. 

I> 

|> o What tells the hardware that an address designates I or D buffer? 

I> 

|> Bit 47. 1 implies buffer. Cache overlaps upper end of buffer. 

I> 

|> o How do we set the cache vs buffer boundaries for I and D? 
I> 

|> Set by 2 bits each cache in Cerberus register, location TBD. 

I> 
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|> o How many outstanding non-blocking loads are allowed? Are they limited 
|> per cylinder or globally? What happens when a request arrives that 
|> overflows the limit? 

I> 

|> 1 6 transactions - any combination of load/store, hexlet/octlet. Cache miss 
|> consumes 4 locations. Global limit. Overflow causes requesting 
j> thread to stall. Details still TBD. 

l> 

|> Action: Need input from architectural simulator on stall behavior. 

I> 

|> o How are non-blocking stores handled? What is their interaction with 
|> nb-loads? 

I> 

|> See above. Same buffer. Occupancy is different though — load 

|> occupies buffer slot until fulfilled request is passed off to 

|> datapath; store until DRAM/Hermes controller accepts request. 

I> 

|> o What *exactly* happens on cache (both i and d) misses, timing-wise? 
|> (When does the line become invalid? *How* does it become invalid? (tag 
\> change, valid bit?) What happens if a different cylinder subsequently 
|> misses on the same line before it becomes invalid? After it becomes 
|> invalid?) 
I> 

|> Details not yet known. Only 1 miss is processed at a time. Missing 
|> thread stalls till resolved. If second thread misses (on any line) it 
j> will stall till first miss is resolved. Line is unavailable from time 
|> of first miss to when it's fully re-written. 

I> 

|> o What are the latencies to various on-chip things: buffer, directly 
|> accessing the cache, reading/writing tlbs, event registers, etc. 

I> 

|> 2 major cycle latency to buffer/cache, event register and timers may 
|> be 1 longer. TLB, tags, indirect cache much slower. Accessed via 
|> physical memory bus after translation. Some serialization will be 
|> performed to minimize data paths, 

l> 

|> o Can we write any and any number of bits in the Euterpe events register 
|> thru software and cause the rthread to run? 
|> Yes. 

I> 

|> o Are accesses to on-chip registers restricted to octlet-access only? 

|> octlet and hexlet? any size? 

I> 

|> Octlet only to fast registers (event, timers). Tbr wants octlet only 
|> to all on chip, but will end up the same as the non-blocking load case 
|> (when that is resolved). 
I> 

Jay Tomlinson MicroUnity Systems Engineering, Inc. 

woody@MicroUnity.com +1 408 734 8100 Fax:408-734-8136 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Thursday, October 06, 1994 4:41 PM 
'Craig Hansen' 

'dickson@aphrodite'; 'euterpe@aphrodite' 
Re: Shift overflows 


Craig Hansen wrote (on Thu Oct 6) : 

> This note is to clarify that we have not implemented the overflow 

> exceptions on shift operations. We do not have spare atoms in the 

> data path. My understanding is that this has zero impact on the set 

> top application. 


> The affected opcodes are 

> ESHLO, ESHLUO (behave the same as ESHL) 

> ESHLIO, ESHLUIO {behave the same as ESHLI) 


These overflow checks use the result computed by the ELMS and EULMS 
hardware to check for overflow. They should not require additional 
data path hardware . 

Please see my other mail asking for clarification of the definition of ELMS and EULMS . I 
need you to discuss this with dickson. He does not agree it's free because he needs both 
leading 0 and leading 1 and firther thinks it would take several issue slots which would 
require a sequencer. 


> 


Tim 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Thursday, October 06, 1994 4:44 PM 
'craig@aphrodite' 
'euterpe@aphrodite' 
I buffer proection 


Here's another one we need an answer for please: 

In article < 1994 04 080456 . VAAO 104 2 ©aphrodite . microunity. com> , 
tbr@aphrodite.microunity.com (Tim B. Robinson) writes: 
> 

> There is a problem with protection of the IB now we have doubled the 

> throughput of the Dcache since the I side no longer has access to the 
GTLB. 

| > Craig proposes an architecturally defined register to set the 
protection 

|> granularity. Crossing a protection boundary or taking a branch 

I > causes 

the 

> I side to steal a cycle from the GTLB and cache the accessed entry. 
> 

> Action: Craig to define this register 


> 


Tim 
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Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Thursday, October 06, 1994 4:47 PM 
'Jeff Marr' 
'euterpe@gaea' 


Jeff Marr wrote (on Thu Oct 6) : 

In article <19940ct6 . 175112 . 24 2 2 6@microunity . com>, jeffm@MicroUnity.com (Jeff Marr) 
writes : 

> tbr asked me to (using no capital letters) find out how many major cycles 

> it takes to enter and leave an exception handler, based on a quick look 

> at a single test, it takes 10 major cycles to enter a handler, and 7 major 

> cycles to leave it (counting bback as part of leaving) . 


I looked at a few more cases, and the number of major cycles to enter the 
handler is higher than I had thought - 15 major cycles is much more typical. 
This is from the point where the instruction that causes the exception 
issues down the pipe (the cases that I looked at are reserved 
instructions) 

till the first instruction of the handler issues. I am not sure what different 
timing characteristics a cache miss will have. It won't be any faster, I don't 
think. The time to return from an exception is pretty accurate: 6-7 major 
cycles is what I see. 

Illegal ops can be detected earlier which would account for the 
difference. An I cache miss will be detected at issue time so should 
be similar to the illegal op case. 


> jeffm 
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Subject: 


Sent: 
To: 

Cc: 


From: 


lisa 

Thursday, October 06, 1994 5:39 PM 
'Derek IversorY 
'gmo'; 'veena' 

Re: Question about terp assemly languange and tgcc... 


> From doiOdemeter Thu Oct 6 15:17:05 1994 

> Subject: Question about terp assemly languange and tgcc... 
> 

> Veena and I have some questions for you. . . . 

> We were wondering if there were going to be a full set of mnemonics 

> for "'ewthi' like there is for "gwthi 1 ? 

The full set of "gwthi's contains one for each group size. I believe that there is only 
one "ewthi' instruction, which operates on one (64 -bit) register. Please let me know if 
there is something I'm obviously missing... 


lisa 
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From: 
Sent: 
To: 


Subject: 


tbe@microunity.com 

Thursday, October 06, 1994 5:41 PM 

'hestia@microunity.com'; 'tbr@microunity.com'; 'lisar@microunity.com'; 
'wayne@microunity.com'; 'jt@microunity.com'; 'khp@microunity.com'; 
'graham@microunity.com'; 'abbott@microunity.com' 
FlashPROM Sockets for initial boards 


First Wayne Freitas wrote: 

To support the bring-up effort we need to be able to program the EEPROM's off of the 
maihboard. If I provide a socket to use does any- body have a problem with loading the 
initial PCA's with sockets in place of the EEPROM's 

Wayne 

To which Tim Robinson replied: 

It's not clear we will need to make changes to the EE PROM off the board, though we do 
need an intial progem in there before it's loaded on the board. We intend to make that 
initial program totally trivial, essentially just a branch that forces code to be fetched 
from cerberus space. We will have verifyed this specific configuration as part of the 
verification process befoer tapeout, so we would have no reason to expect a problem with 
this approach. 


To which Craig Hanson rejoined: 

A socket for the EE PROM should not be required. Euterpe must be able to boot from 
Cerberus directly by configuring the Cerberus address of Euterpe. 


Which discouraged me from looking much further at the issue, so I posted: 

The current package for the EEPR0M is a T-SOP (.0198" pitch) . I know of no socket for 
such a package. There is precious little room under Euterpe on the side where the 1/0 
pads are for a larger package, as I suspect a PLCC would be. Pattie is concerned about 
fitting the vias and traces as is, and I am concerned about accomodating not just the 
PLCC but the socket. 
Theses 

sockets that use the same land pattern are a mixed bag, in my experience. 

They are somewhat fragile and although they use the original parts land pattern, they 
can be hard to reflow and rework. Not a standalone reason against using them for first 
units, but I doubt that they will fit. If someone can id an equivalent EEPR0M in a PLCC, 
we can conclusively assess fit. 


After which Kevin Peterson provided spec sheets (thanks) for the same Atmel part in a PLCC 
(socketable) . 

Meanwhile, Guillermo posted: 

Regardless of what other ways we may have to get the very first bytes of code into 
Euterpe, I believe it will be useful to be able to create EE PROMS offline during the 
bringup phase. It maybe redundant if everything- else- works- first- time- out , but with so 
many variables a little reduandancy sounds really good. Besides, the eeprom is the 
easiest path for the first instructions since it does not depend on getting the CBI 
(Cerberus Bus Interface) and all the associated software to work correctly. 


Now, I understand that the issue of debuggability and specifically the socketing of the 


Tim 


Craig 


-Tom 


Gmo. 
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EEPROM came up in the Software group's meeting today. 

This reminded me that I needed to respond to this thread anyway, since reviewing the Atmel 
spec sheets received from khp. 

The PLCC with socket should fit in the area that the TSOP is currently placed in on the 
main pcb layout. We already have 70 pieces of the TSOP in stock (~$20 ea.) . I don't know 
the lead time for the PLCC. 

So, what is the decision regarding socketing the EEPROM? I see no MECHANICAL design 
reason that would preclude a socketed part. Box size is not an issue here. Speak now or 
forever hold your probes I 

-Tom 


Tom Eich tbe@microunity.com 
MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, (408)734-8136 fax 
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To: 


Cc: 


Sent: 


From: 


Lisa Robinson [lisar@nosferatu] 
Thursday, October 06, 1994 6:31 PM 
'doi@nosferatu'; 'hopper@nosferatu' 
'tbr@nosferatu'; 'tom@nosferatu' 


Subject: doi.verilog 


Can we get this verilog installed in the right place. 
This is the KLUDGE put into euterpe/veriog/bsrc 
DOIVERILOG = 

LM_LICENSE_FILE=$(CHIPROOT)/tools/vendor/cadence/share/license/license.55000dbe/u/doi/src/hermes/doi 

Yes as Tim pointed out I could have just redefined VERILOG_PROG but 
since that would have meant that all of the verilog targets used this 
ie everyone typing bsim I felt that it should be installed correctly. 


Lisa R. 
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From: Wayne Freitas [wayne@echidna] 

Sent: Thursday, October 06, 1 994 6:58 PM 

To: 'hestia@echidna'; 'tbr@echidna'; 'lisar@echidna'; 'jt@echidna'; 'khp@echidna'; 

'graham@echidna'; 'abbott@echidna'; 'tbe@microunity.com' 
Subject: Re: Flash PROM Sockets for initial boards 


> From tbe@MicroUnity.com Thu Oct 6 15:41:11 1994 

> Date: Thu, 6 Oct 94 15:41:04 PDT 

> X- Sender: tbe@gaea.microunity.com 

> Mime -Version: 1.0 

> Content -Type> : > text/plain> ; > charset= "us-ascii" > 

> To: hestia, tbr, lisar, wayne, jt, khp, graham, abbot t 

> From: tbe@MicroUnity.com 

> Subject: FlashPROM Sockets for initial boards 

> Content-Length: 3310 
> 

> First Wayne Freitas wrote: 
> 

> To support the bring-up effort we need to be able to program the 

> EEPROM' s off of the mainboard. If I provide a socket to use does any- 

> body have a problem with loading the initial PCA's with sockets in 

> place of the EEPROM'S 
> 

> Wayne 
> 

> To which Tim Robinson replied: 
> 

> It's not clear we will need to make changes to the EEPROM off the 

> board, though we do need an intial progem in there before it's loaded 

> on the board. We intend to make that initial program totally trivial, 

> essentially just a branch that forces code to be fetched from cerberus 

> space. We will have verifyed this specific configuration as part of 

> the verification process befoer tapeout, so we would have no reason to 

> expect a problem with this approach. 
> 

> Tim 

> 

> To which Craig Hanson rejoined: 
> 

> A socket for the EEPROM should not be required. Euterpe must be able 

> to boot from Cerberus directly by configuring the Cerberus address of 

> Euterpe. 
> 

> Craig 
> 

> Which discouraged me from looking much further at the issue, so I 
posted: 

> 

> The current package for the EEPROM is a T-SOP (.0198" pitch). I know 
of no 

> socket for such a package. There is precious little room under 

> Euterpe 
on 

> the side where the I/O pads are for a larger package, as I suspect a 
PLCC 

> would be. Pattie is concerned about fitting the vias and traces as 

> is, 
and 

> I am concerned about accomodating not just the PLCC but the socket. 
Theses 

> sockets that use the same land pattern are a mixed bag, in my 
experience . 

> They are somewhat fragile and although they use the original parts 

> land pattern, they can be hard to reflow and rework. Not a 
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> standalone 
reason 

> against using them for first units, but I doubt that they will fit. 

> If someone can id an equivalent EE PROM in a PLCC, we can conclusively 
assess 

> fit. 
> 

> -Tom 
> 

> After which Kevin Peterson provided spec sheets (thanks) for the same 
Atmel 

> part in a PLCC (socketable) . 
> 

> Meanwhile, Guillermo posted: 
> 

> Regardless of what other ways we may have to get the very first bytes 

> of code into Euterpe, I believe it will be useful to be able to create 

> EEPROMS offline during the bringup phase. It maybe redundant if 

> everything-else-works- first-time-out, but with so many variables a 

> little reduandancy sounds really good. Besides, the eeprom is the 

> easiest path for the first instructions since it does not depend on 

> getting the CBI (Cerberus Bus Interface) and all the associated 

> software to work correctly. 
> 

> Gmo . 
> 

> Now, I understand that the issue of debuggability and specifically the 

> socketing of the EEPROM came up in the Software group's meeting today. 

> This reminded me that I needed to respond to this thread anyway, since 

> reviewing the Atmel spec sheets received from khp. 
> 

> The PLCC with socket should fit in the area that the TSOP is currently 

> placed in on the main pcb layout. We already have 7 0 pieces of the 

> TSOP 
in 

> stock (~$20 ea.) . I don't know the lead time for the PLCC. 
> 

> So, what is the decision regarding socketing the EEPROM? I see no 

> MECHANICAL design reason that would preclude a socketed part. Box 

> size 
is 

> not an issue here. Speak now or forever hold your probes! 
> 

> -Tom 


> Tom Eich tbe@microunity.com 

> MicroUnity Systems Engineering, Inc. 

> 2 55 Caspian Dr. Sunnyvale, CA 94 089 

> (408)734-8100, (408)734-8136 fax 


Funny you should mention this. I'm still looking into this but you 
might as well know some of the other problems were running into. 
Atmel currently doesn't list any company that makes programmers to 
supports this at this time (they even questioned why we wanted to use 
a programmer) . They said that they did give samples out to a number 
of different company back at the beginning of summer (humm) . I 
called Data I/O, and they indicated that if we provided them a sample 
of the device they would develop the algorithm to support the device 
(they currently support the 29LV512) . I also found a interface socket 
(TSOP -> DIP) that would allow us to program the device on the Data 
I/O 3900 one way or the other. If we can fit/use the PLCC it would 
be alot easier, if not well have to come up with some form of kludge 
(yuck) . I vote for trying to use a PLCC, but then I'm just trying to 
make my job a little easier for once. 
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To: 


Sent: 


From: 


Tom Laidig [tom@clio] 

Thursday, October 06, 1994 7:08 PM 

'Lisa Robinson' 


Cc: 'doi@nosferatu'; 'hopper@nosferatu'; 'tbr@nosferatu'; 1om@nosferatu' 
Subject: Re: doi.verilog 

Lisa Robinson writes: 
I 

|Can we get this verilog installed in the right place. 

I 

[This is the KLUDGE put into euterpe/veriog/bsrc 
I 

IDOIVERILOG = 

LMJJCENSE_FILE=$(CHlPROOT)/tools/vendor/cata 
I 

| Yes as Tim pointed out I could have just redefined VERILOG_PROG but 
I since that would have meant that all of the verilog targets used this 
jie everyone typing bsim I felt that it should be installed correctly. 

I guess I'm out of touch... what is 'doi.verilog'? Is it a new 

version from cadence, a version linked with some PLI code, or what? 


Tom L 
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From: 


tbr 


Subject: 


Cc: 


Sent: 


To: 


Thursday, October 06, 1994 7:13 PM 
'tbe@MicroUnity.com' 

'abbott'; 'graham'; 'hestia'; 'jt'; 'khp'; 'lisar'; 'wayne' 
Flash PROM Sockets for initial boards 


Follow Up Flag: Follow up 
Flag Status: Red 


tbe@MicroUnity.com wrote (on Thu Oct 6): 
Now, I understand that the issue of debuggability and specifically the 
socketing of the EEPROM came up in the Software group's meeting today. 
This reminded me that I needed to respond to this thread anyway, since 
reviewing the Atmet spec sheets received from khp. 

The PLCC with socket should fit in the area that the TSOP is currently 
placed in on the main pcb layout. We already have 70 pieces of the TSOP in 
stock (~$20 ea.). I don't know the lead time for the PLCC. 

So, what is the decision regarding socketing the EEPROM? I see no 
MECHANICAL design reason that would preclude a socketed part. Box size is 
not an issue here. Speak now or forever hold your probes! 

We were aware of the PLCC version of this part all along, but at an 
early starge and for some reason which now escapes me, but it seemed 
good at the time, we rejected using it in favor of the tsop. It may 
have been related to inspectability. 

Per craig's requirement, we will need a jumper on the board to allow 
the Cerberus address of euterpe to be changed. That in turn will 
control whether the initial fetch is to Cerberus or the ROM. Assuming 
we have the cerberus server that means we should be able to start up 
with nothing in the flash rom removing the absolute requirement to be 
able to program it externally. 

Is it determined that with the PLCC, socket and part will fit the same 
footprint? I think we need to be sure of that before designing the 
board always to require the socket. Sockets are a source of 
unreliability in production. I also state again the potential 
requirements for tamper resistance wrt the ROM. 

For prototypes I have no problem with a socket, but I'd sooner leave 
it out and trust our simulations to tell us that the Cerberus 
interface will in fact work. 


Tim 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Bob Morgan [bobm@microunity.com] 

Thursday, October 06, 1994 7:24 PM 

'euterpe@gaea' 


I'm right now in the process of checking in release 1.3 of the MicroArchitecture document. 
It incorporates more of the comments I have received and most of the changes that have 
come around in the last week. As usual, you can use the Makefile to print out the book, 
or let me know if you want a bound copy. 

And of course, more comments are always welcome. 

Thanks , 

Bob 
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From: tbe@MicroUnity.com 

Sent: Thursday, October 06, 1994 8:05 PM 

To: Tim B. Robinson' 

Cc: 'abbott@MicroUnity.com'; 'graham@MicroUnity.com'; , hestia@MicroUnity.com'; 

'jt@MicroUnity.com'; 'philip@MicroUnity.com'; 'khp@MicroUnity.com'; 'wayne@MicroUnity.com'; 
'lisar@MicroUnity.com' 

Subject: Re: FlashPROM Sockets for initial boards 

On October 6, Tim Robinson wrote: 
>tbe@MicroUniry.com wrote (on Thu Oct 6): 

> Now, I understand that the issue of debuggability and specifically the 

> socketing of the EEPROM came up in the Software group's meeting today. 

> This reminded me that I needed to respond to this thread anyway, since 

> reviewing the Atmel spec sheets received from khp. 

> 

> The PLCC with socket should fit in the area that the TSOP is currently 

> placed in on the main pcb layout. We already have 70 pieces of the TSOP in 

> stock (~$20 ea.). I don't know the lead time for the PLCC. 

> 

> So, what is the decision regarding socketing the EEPROM? I see no 

> MECHANICAL design reason that would preclude a socketed part. Box size is 

> not an issue here. Speak now or forever hold your probes! 

> 

>We were aware of the PLCC version of this part all along, but at an 
>early starge and for some reason which now escapes me, but it seemed 
>good at the time, we rejected using it in favor of the tsop. It may 
>have been related to inspectability. 

> 

>Per craig's requirement, we will need a jumper on the board to allow 
>the Cerberus address of euterpe to be changed. That in turn will 
>control whether the initial fetch is to Cerberus or the ROM. Assuming 
>we have the cerberus server that means we should be able to start up 
>with nothing in the flash rom removing the absolute requirement to be 
>able to program it externally. 
> 

>Is it determined that with the PLCC, socket and part will fit the same 
>footprint? I think we need to be sure of that before designing the 
>board always to require the socket. Sockets are a source of 
Unreliability in production. I also state again the potential 
Requirements for tamper resistance wrt the ROM. 
> 

>For prototypes I have no problem with a socket, but I'd sooner leave 
>it out and trust our simulations to tell us that the Cerberus 
>interface will in fact work. 

> 

>Tim 

The Manufacturing issues wrt TSOP vs. PLCC are, according to jr: 

1) Ease of initial reflow—TSOP has direct line of sight to solder joints 

2) Ease of inspection— direct line of sight 

3) Ease of rework- less heat required to remove TSOP, but more care 
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required in replacing due to finer pitch leads. 

So given a choice (which is what we took), TSOPs are preferred. 

Given what you say above, it sounds like its ok to proceed with the TSOP. 
However, Wayne has raised a TSOP fixture issue in addition to the lack of 
programmers for this device. We need to close on this decision as Pattie 
is planning to work Saturday to finish placement and much of the 
preliminary routing. Please advise. 


Tom Eich tbe@microunity.com 
MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, (408)734-8136 fax 
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Subject: 


To: 


From: 


Sent: 


Cc: 


tbr 

Thursday, October 06, 1994 11:02 PM 
Tom Laidig' 

'doi@nosferatu'; 'hopper@nosferatu'; 'Lisa Robinson'; , tom@nosferatu' 
Re: doi.verilog 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Thu Oct 6): 

Lisa Robinson writes: 
I 

| Can we get this verilog installed in the right place. 
I 

| This is the KLUDGE put into euterpe/veriog/bsrc 
I 

IDOIVERILOG = 

LM_LICENSE_FILE=$(CHIPROOT)/tools/vendor/cadence/share/Hcense/license.55000dbe/u/doi/src/hermes/doi. verilog 
I 

| Yes as Tim pointed out I could have just redefined VERILOG_PROG but 
[since that would have meant that all of the verilog targets used this 
jie everyone typing bsim I felt that it should be installed correctly. 

I guess I'm out of touch... what is 'doi.verilog'? Is it a new 

version from cadence, a version linked with some PLI code, or what? 

It's something your nasty nits program once told me to stop using! 

It's a special version linked with a behavioral PLI modle of a generic 
hermes device. 


Tim 
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From: vant [vanthof@hestia] 

Sent: Friday, October 07, 1 994 1 2:04 AM 

To: 'Orlando Hernando'; 'Mike Wageman' 

Cc: 'Dave Van't Hof ; 'Mark Hofmann'; 'Geert Rosseel'; 'Tom Vo'; 'Tim B. Robinson'; 'Lisa 

Robinson' 

Subject: floating poly checks for euterpe finished 


The floating poly check for euterpe finished and it's unfortunately 1.4MB. 
I was wondering if you could look at this for me? 

The file is: /u/vanthof/ compass /mobi/ euterpe/ float_poly . err 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! (tm) All kids love Log! #incluce 
<std_disclaim.h> 
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To: 


Sent: 


From: 


Tom Laidig [tom@clio] 

Friday, October 07, 1994 11:06 AM 

'Brian Lee' 


Cc: 'tbr@aphrodite'; 'brianl@marathon'; , tom@marathon' 
Subject: Re: custom/toptlist 

Brian Lee writes: 
I 

|Tim B. Robinson writes: 
II 

||Why is this one in the list? I thought it was only used *inside* 
jjiobyte which is itself a leaf cell as far as topt/gards is concerned. 
II 

||custom io01df4s ioOI df f4s gate Op na 1 
II 

||It causes a warning from topt: 
II 

J| Reading Legal Cell List file /n/auspex/sl 5/tbr/euterpe/proteus/custom/toptList 

||ReadLega1CellFile: Warning! No atoms info for io01df4s 

I 

1 1 think that this was originally requested by rich. I'm not sure that 
jit is in iobyte either. It is a copy of an "old-style" 01 generator. 
jHowever, I believe that it is no longer being used now. I'll check and 
jremove it if necessary. 

That's correct. The netlist has been changed back to using the xbcOl 
cell. 


Tom L 
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From: Bruce Bateman [stick@kephalos] 

Sent: Friday, October 07, 1994 12:48 PM 

To: 'tbr@aphrodite' 

Cc: 'hardheads@hestia'; 'solo@echidna'; 'vanthof@hestia' 

Subject: Re: layout checkins 


> Date: Fri, 7 Oct 1994 10:29:43 -0700 

> From: tbr@aphrodite (Tim B. Robinson) 

> To: stick@kephalos {Bruce Bateman) 

=> Cc: hardheadsohestia, solo@echidna , vanthof ©hestia 

> Subject: Re: layout checkins 

> Bruce Bateman wrote (on Fri Oct 7) : 
> 

> Regarding item 3a - if your intent here is that schematics shouldn't 

> be released until the same time as the layout, this presents a 
problem. 

> Checked- in schematics go into /u/chip/chip-archive/PROJECT/ged/DIR 
and 

> then get moved to /u/chip/PROJECT/ged/DlR when released. But we've 

> set up the Concept/Ged library pointers to point the "released" 

> /u/ chip/ PROJECT version, so the only schematics anyone can see 
without 

> checking them out are the released schematics. (This differs from 

> what we are doing on the layouts where we have compass point to 

> /u/chip/mdunit where the checked- in but not necessarily released 

> layouts reside.) Thus, if I complete a schematic, along with sim's, 

> csyn, etc and thus consider the circuit design complete, even though 

> I check it in, unless I also release it, no one else can refer to it 

> or use it in a portion of their design unless they check-out a local 

> copy. Perhaps we should make schematics work the same way as we've 

> set-up the layout pointers, with Concept/Ged pointing to the check- in 

> database rather than to the release database. 
> 

> In the case of the layouts, don't you see the released version in 

> prefernce to the local version? I assume you only want ot see the non 

> released version if there is no released version. 
> 

> Tim 


The way I have my vlsi.boo set (which I believe is consistent with how dave said to do it 
when we switched to the mdunit database) is: 

cell_library proteus /u/chip/mdunit /proteus/compass/ layouts 

cell_library proteusleaf /u/chip/proteus/compass/leaf 
cell_library euterpebase /u/chip/euterpe/compass/baseplate 

There is no pointer to /u/chip/proteus/compass/ layouts where the "released" layouts 
reside, thus, as I understand it, I'm only seeing the most recent checking, not the 
released copy. Perhaps there should also be a something like proteusrel which points to 
the released version in /u/chip/proteus/compass/ layouts . But then this would be roughly 
equivalent to the old "proteus_locked" 

that we used to have. I thought that was what we were trying to get away from. Dave? 
BB 
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From: Tom Laidig [tom@clioj 

Sent: Friday, October 07, 1994 12:52 PM 

To: 'Bruce Bateman' 

Cc: 'hardheads@clio'; Thomas Laidig' 

Subject: Re: layout checkins 


Bruce Bateman writes: 

> Date: Fri, 7 Oct 1994 10:29:43 -0700 

> From: tbr@aphrodite (Tim B. Robinson) 
> 

> In the case of the layouts, don't you see the released version in 

> prefernce to the local version? I assume you only want ot see the 

> non released version if there is no released version. 
> 

> Tim 


The way I have my vlsi.boo set (which I believe is consistent with how 
dave said to do it when we switched to the mdunit database) is: 

cell_library proteus /u/chip/mdunit /proteus/compass/layouts 

cell_library proteusleaf /u/chip/proteus/compass/leaf 
cell_library euterpebase /u/chip/euterpe/compass/baseplate 

There is no pointer to /u/chip/proteus/compass /layouts where the 
"released" layouts reside, thus, as I understand it, I'm only seeing 
the most recent checking, not the released copy. Perhaps there should 
also be a something like proteusrel which points to the released 
version in /u/ chip/proteus /compass/ layouts . But then this would be 
roughly equivalent to the old "proteus_locked" 

that we used to have . I thought that was what we were trying to get 
away from. Dave? 

There would be no effect if you added a pointer to /u/chip/proteus/compass/layouts , since 
the cell names are the same as those in /u/chip/mdunit /proteus /compass /layouts, and 
compass will simply use the cell in the first place it finds it. 

Basically, you have your choice of pointing to the released area or the checkin area 
and you can't do any modifications if you point to the released area. 


Tom L 
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From: vant [vanthof@hestia] 

Sent: Friday, October 07, 1 994 1 :02 PM 

To: 'Bruce Bateman' 

Cc: 'hardheads@hestia'; 'Dave Van't Hof 

Subject: Re: layout checkins 


Bruce Bateman writes: 

>The way I have ray vlsi.boo set (which I believe is consistent with how 

>dave said to do it when we switched to the radunit database) is: 

> 

>cell_library proteus /u/chip/mdunit/proteus/compass/layouts 
>cell_library proteusleaf /u/chip/proteus /compass/leaf 

>cell_library euterpebase /u/chip/euterpe/corapass/baseplate 
> 

>There is no pointer to /u/chip/proteus/compass/ layouts where the 
>"released" layouts reside, thus, as I understand it, I'm only seeing 
>the most recent checking, not the released copy. Perhaps there should 
>also be a something like proteusrel which points to the released 
>version in /u/chip/proteus/compass/ layouts . But then this would be 
>roughly equivalent to the old ,1 proteus_locked" 

>that we used to have. I thought that was what we were trying to get 

>away from. Dave? 

> 

>BB 


For editing layouts, your vlsi.boo file is correct. For verification, then I believe 
solo's vlsi.boo file is correct (referencing the /u/chip/proteus/... not 
/u/chip/mdunit/proteus/ . . . ) 

Releaseing a layout means that it and it's children are 'done'; they are lvs/drc clean. 
For any sort of verification, only released layouts should be referenced. 

/u/chip/mdunit/proteus/compass/ . . . should be treated as if it were your own 'local copy', 
when you are done with a cell, then it needs to be released, much like schematics, 
verilog, etc. This allows 'others' to see the finished layouts in the 
/u/chip/proteus/compasws/ . . . tree. 

It don't think adding a proteusrel to the search path (allowing people to see both 
released and non-released layouts) would work very well. This bypasses the concept of the 
BOM and would make verifying layouts very confusing. 

If you want to do edits _and_ verify released layout correctness, then you will need to 
somehow uniquely reference the two libraries in different compass sessions. You should 
not reference both of them in the same compass window. 

Hope this helps. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
< std_disclaim . h> 
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From: Curtis Abbott [abbott@tallisl 

Sent: Friday, October 07, 1 994 1 :26 PM 

To: 'dickson@tallis'; 'euterpe@tallis'; 'softheadsfgtallis' 

Subject: icache miss 


Richard Dickson wrote (on Wed Oct 5) : 
you' all, 

if i cache misses were handled by an exception and software 
handled the icache line fills what would be the short comings. 

i realize one of us 'hardware weenies' in the past said it 
would be easy to implement a gate level controller for this 
function. 

given that it would take at least 200-250 minor clock cycles 
to fetch the data from dram no matter how its done would a 
software controlled icache add significantly to this 
total . 

from where i stand there are two advantages to a software only 
solution. 

1) fewer gates 

2) we will finish the euterpe logic design sooner 


dickson 

Richard - 

A number of software people, especially Lisa, Gmo and myself, have been discussing the 
issue you raise. The conclusion is that given one hardware change, the extra overhead for 
software-based I cache miss fulfillment is significant, probably around 8 0 major clock 
cycles . 

The hardware change is to place the physical address and protection bits (from the GTLB) 
in the exception register. Without this change, the overhead would probably triple. 
Although you didn't mention it, we've also talked about D cache miss handling. For this, 
the corresponding hardware change would require quite a bit more redesign, else the 
overhead probably doubles again (to something like 5x the best -case miss handling time) . 
So D cache handling looks a lot less feasible. 

So, we think the way to resolve this issue is to get a few people together to discuss the 
implications of our analysis, better understand your difficulties with doing it in 
hardware, hash out the tradeoffs, and make a decision. 


What's involved in software-based I cache miss fulfillment? In general, to handle an I 
cache miss, we need to 1. write the tag in such a way as to invalidate it (we think this 
can be overlapped with step 2) . 

2 . read 4 hexlets worth of data from the physical address corresponding to the virtual 
address that caused the cache miss and store them into the cache line. (more exactly, 
different virtual addresses that map to the same physical addresses with the uncached 
attribute . ) 

3. write the new virtual address to the cache tag for the corresponding line. 

Note that there are further steps in D cache miss fulfillment concerning writeback. As a 
result, there are more addresses (virtual and physical) involved. This makes D cache miss 
fulfillment considerably more complicated than I cache miss fulfillment. 

One of the big issues for software -based cache miss handling is getting the information 
(physical address and protection bits) normally provided by the GTLB. If you do this in 
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software, it will take hundreds of instructions. The hardware could provide it in the 
exception register. Since PA's are 48b, protection is 16b, and exception register is 64 
bits, there are enough. So, this is the hardware change that makes the software overhead 
possibly tolerable. 
Is this a problem? 

The largest contribution to software overhead will be saving and restoring registers, 
setting up address pointers from a literal pool, etc. This can be optimized, but not 
optimized away. 

Probably the second most important issue is the fact that there 1 s only one software entry 
point for exceptions AND interrupts. Right now, the code at that entry point deprecates 
exceptions, because they're not supposed to happen. We'd have to redesign that code -- 
one of the uncertainties in our analysis is that we don't know exactly how the code would 
come out. Basically, there's some overhead in figuring out that the exception/interrupt 
cause is an icache miss and branching (yes, branching) to the handler. 

Another issue is serializing handling of multiple I cache misses. 

This isn't really necessary as long as the misses go to different lines, but if hardware 
doesn't serialize at least these, software must. This adds setup, register save/restores, 
and 2 atomic ops to the critical path -- something like 16 major cycles of overhead. 

However, in Euterpe exceptions serialize across the machine. This solves the 
serialization issue for the handler, at no real cost for the current application. It will 
degrade performance, however, in a software design (such as Un*x) where tlb miss 
exceptions are used for page faults . 

Note that in any case, hardware must handle the hazard associated with the times during 
which the cache tag is being written. This is an inter-barrel thing, about which software 
has no control . 

In order to make our analysis less of a handwave, Lisa wrote and hand- optimized much of 
the necessary code. What's missing from her work is more efficient integration into the 
startup/f inalization code. 

Lisa's code is at the end of this message. It looks like the startup could be reduced to 
about 4 0 major cycles, including the 10 cycles to generate the exception. The overhead in 
the imiss_handler and exit sequence appears to also be about 4 0 major cycles, including 
the 6 to do a b.back. The code is very load/store intensive, so schedules at about 0.5 
IPC. 

In the settop application, we hope to completely flush the I cache at about a 100Hz rate. 
If we achieve this, software -based icache miss handling appears to lose about 1% of the 
thread's cycles -- 256 lines at 100Hz at 80 overhead cycles/miss. (Note that total icache 
miss fulfillment time is probably 2-5%, depending on NB usage the 1% only counts 
software overhead, not the time to get the line from 
DRAM. ) 


Lisa's code: 


! the startup code to get to the imiss_handler is omitted 

imiss_handler : 

sl28ai no, dp, im iss_s crate ho -_cxt_switch_litpool 

164ai r4,r61,SR_EXCEPTION_ADDR 

sl28ai rl2 , dp, imiss_scratchl-_cxt_switch_litpool 

164ai r3 , dp, terp_phys_base-_cxt_switch_litpool 

sl2 8ai rl4 , dp, imiss scratch2- cxt switch_litpool 

euwthi r2,r4,48,0 ! physical address 

eandi r2,r2,-64 ! cache line aligned 

eor r2,r2,r3 ! uncached virtual mapping 

sl2 8ai rl6,dp, imiss scratch3- cxt_switch_litpool 


1128ai 
H28ai 
1128ai 
1128ai 


rl0,r2, 0 
rl2,r2,16 
rl4,r2,32 
rl6,r2, 48 


I get the line from DRAM 
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/* 

* Now we want to get : 

* r2 - cache tag address 

* r3 - cache line address 

* r4 - good tag 

* We aren't in a big hurry; those four loads above will take awhile. 
*/ 

euwthi r2,r4,2,50 ! the execution privilege 

euwthi r3,r4,6,56 ! cc, da, ao, and cs fields (6 bits) 

eor r2,r2,r3 ! combined into tag prot field 


164ai r4,dp,_event_vector_addr-_cxt_switch_litpool 

eshli r3 , r60 , TERP_EVENT_VEC_SHIFT 

164a r0,r4,r3 ! the pc and eel 

ecopyi r 3, -163 84 

eand r3,r0,r3 1 local-virtual pc, cache line aligned 

I64ai r4 , dp, local_tlb_addr-_cxt _switch_litpool 

164ai r4,r4,0 ! local tlb entry 

euwthi r4,r4,16,16 i the xor field 

eshli r4,r4,48 ! where it gets xor'd 

exor r4 , r3 , r4 ! the global -virtual tag 

eor r4,r4,r2 ! the whole tag (addr + protection) 


euwthi r0,r0,8,6 


cache line index 


164ai r2 , dp, icache_tag_addr-_cxt_switch_litpool 
eshli rQ,rO,3 ! byte offset of cache tag 

eadd r2 , r2 , rO ! cache tag address 


164ai r3 , dp, icache_addr-_cxt_switch litpool 

eshli r0,r0,3 J byte offset of cache line 

eadd r3 , r3 , rO ! byte address of cache line 

/* 

* When we get here, we have: 

* r2 - cache tag address 

* r3 - cache line address 

* r4 - good tag 
*/ 

ecopyi rO,-l ! "invalid tag" (is -1 good enough???) 

s64ai 

sl28ai 
1128ai 
sl28ai 
1128ai 
sl28ai 
1128ai 
sl28ai 
1128ai 


rO , r2 , 0 


J store invalid tag 


rl0,r3, 0 

rlO ,dp, imiss_scratchO-_cxt_switch_litpool 
rl2,r3,16 

rl2 , dp, imiss_scratchl-_cxtswitch_litpool 
rl4,r3,32 

rl4 , dp , imiss_scratch2 -_cxt_switch_litpool 
rl6,r3,48 

rl6 , dp, imiss scratch3 -_cxt_switch_litpool 


store good tag 


s64ai r4,r2, 0 
restore_work_regs : 

! this would be changed to use fewer load/stores and be faster 


r3, r6 0, CURCYL_MASK 

r3, r3, EL_PER_CYL_SHIFT 


1 current cyl number 
! compute offset in orig 


eandi 
eshli 
lpool 

164ai r2, dp, event_litpool_addr - _cxt_switch_litpool 
eadd r4, r2, r3 ! addr of orig lpool for 

curcyl 
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1128ai 

I64ai 

1128ai 

164ai 

164ai 

bback 


r2 , r4 , EL_SAVE_REG_PAIR 
r4 , r4 , EL_SAVE_REG 
r60, sp, SV_R60 
rO, sp, SV_RO 
Sp, sp, SV_SP 


restore r2, r3 
restore r4 
restore r60, r61 


rl by bback 
restore sp 


The conclusion is that for I cache miss handling, there are major simplifications (and 
hence, speedups) for software relative to the general case. There are some extra 
overheads. The critical path looks something like this: 

1. exception taken (15 cycles) 

2. save 2 regpairs (6 cycles avg, to sync with store issue restriction) 3. load or 
construct exception register & cache tag base addrs (4 cycles) 4. load saved PC to get 
VAddr that missed (2 cycles) 5. mask VAddr, construct invalid tag value (2 cycles) 6. 
store invalid tag (2 cycles) 7. load exception register to get PAddr that missed (2 
cycles) 8. convert PAddr to uncacheable VAddr {2 cycles) 9. load first hexlet of cache 
line from DRAM (many cycles) ... (do 4 hexlet s, possibly saving & restoring more regpairs 
while waiting) k. format new VAddr, store to cache tag (2 cycles) 

k+1. load 2 regpairs (4 cycles) 
k+2 . b.back (7 cycles) 

So it looks like the extra software overhead/cost (compared to the contemplated hardware 
implementation) would be something like 26+C major cycles, where C is the cost of taking 
an exception and doing the corresponding b.back. This assumes the hardware supplies the 
physical address that missed in the exception register, which is not normally done. The 
miss fulfillment code sketched here is load/store intensive, so it won't compact much (in 
cycle count) . We haven't written and optimized it, but there's hope the inevitable 
shifts, ecopyi's, etc., will fit in around the load/stores without poking their nose onto 
the critical path too often. 

The SRAM costs look to be order 50 instructions and 10 octlets for save areas & literals, 
or 80 bytes of DBUF and 200 bytes of IBUF. 

- multi-thread 

- exception serialzn exacerbates lockout 

- cerb useless 
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From: tbr 

Sent: Friday, October 07, 1994 1:58 PM 

To: 'woody' 

Cc: 'vo'; 'dickson' 

Subject: verilog warning 

Follow Up Flag: Follow up 

Flag Status: Red 


Verilog is giving me 

Warning! Implicit wire has no fanin [Verilog-IWFA] 
"euterpe.v", 325: test_vref 

in the latest BOM. Can you check it out please? 
Tim 
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From: Jay Tomlinson [woody@melpomene] 
Sent: Friday, October 07, 1994 2:16 PM 
To: Tim B. Robinson' 
Cc: 'dickson@aphrodite'; 'vo@aphrodite' 
Subject: verilog warning 

It is just a missing wire del. I will fix it. 
Jay 

Tim B. Robinson wrote (on Fri Oct 7): 
Verilog is giving me 

Warning! Implicit wire has no fanin [Verilog-IWFA] 
"euterpe.v", 325: test vref 

in the latest BOM. Can you check it out please? 

Tim 
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From: Mark Semmelmeyer [mws@clytemnestra] 

Sent: Friday, October 07, 1 994 4:29 PM 

To: Tim B. Robinson'; 'Jeff Marr' 

Cc: 'euterpe@clytemnestra* 

Subject: Re: exception entry speed 


Tbr wrote : 

> > Jeff Marr wrote (on Thu Oct 6) : 

> > 

> > In article <I9940ct6.l75112.24226@microunity.com>, 
jeffm@MicroUnity.com (Jeff Marr) writes: 

> > 

> > \> tbr asked me to (using no capital letters) find out how many 

> > | > major 
cycles 

> > | > it takes to enter and leave an exception handler, based on a 

> > j > quick 
look 

> > j > at a single test, it takes 10 major cycles to enter a handler, 

> > j > and 
7 major 

> > |> cycles to leave it (counting bback as part of leaving) . 

> > | 

> > |> jeffm 

>>!>-- 

> > I looked at a few more cases, and the number of major cycles to 

> > enter 
the 

> > handler is higher than I had thought - 15 major cycles is much more 
typical . 

> > This is from the point where the instruction that causes the 

> > exception issues down the pipe (the cases that I looked at are 

> > reserved 
instructions) 

> > till the first instruction of the handler issues. 

This is the correct way to measure it. The fastest event entry should be 
14 major cycles, and the slowest 17 major cycles. This variation is caused by the entry 
microcode wiating for a store slot in which to save the old Rl and PC. The fastest occurs 
when the instruction receiving the exception or being cancelled by an interrupt issues in 
a load slot that is not a store slot. The slowest is in the next slot. Additional delays 
should only occur when the exception status register is unavailable. 

> > I am not sure what different 

> > timing characteristics a cache miss will have. It won't be any 

> > faster, I don't think. 

A cache miss as an exception would be the same. 

> > The time to return from an exception is pretty accurate: 6-7 major 

> > cycles is what I see. 

You should always see 6 unless you are counting 1 for the case where the bback is waiting 

for a load slot (but this is not the issue- to- issue measurement method) . 

> 

> Illegal ops can be detected earlier which would account for the 

> difference. An I cache miss will be detected at issue time so should 

> be similar to the illegal op case. 

Actually we make no effort to process earlier-known exceptions earlier because we have to 
wait for all previous instructions to become known to produce no exceptions or hiccups (we 
wait for the commit point) . 

We could not even do a reserved instruction exception early if we somehow knew the 
previous instructions were exception free because the icache miss detection for our own 
instruction is very late in the pipe (not at issue time) and we don't want to take a 
reserved exception instead of the miss. 


Exhibit C7 


Page 148 of 703 


From: 
Sent: 
To: 

Subject: 


craig 

Friday, October 07, 1994 4:47 PM 
'euterpe@gaea'; 'jeffrr^microu nity.com' 
HW icache fills 


>Let ' s not forget that many of the gates necessary to implement HW 
>icache fills are also needed to implement uncached ifetch from Flash 
>Rom, Cerberus, and dram. 

>The savings from eliminating HW icache fills may not be a great as at 
>first glance. 


Icache fills aren't necesarily from DRAM; an important case is Icache refill via Hermes 
from a Mnemosyne, which can have much lower latency. An 8 0 cycle penalty sounds rather 
large, given the small Icache size we've got. 


> j ef fm 


Craig 
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From: Mark Semmelmeyer [mws@clytemnestra] 

Sent: Friday, October 07, 1994 5:05 PM 

To: 'Jeff Marr' 

Cc: 'euterpe@clytemnestra' 

Subject: Re: your mail 


jeffm wrote: 

> From: dickson@demeter (Richard Dickson) 

> To: sof theads@demeter 

> Subject: icache miss 

> Date: Wed, 5 Oct 1994 16:30:22 -0700 
> 

> if i cache misses were handled by an exception and software 

> handled the icache line fills what would be the short comings. 

> from where i stand there are two advantages to a software only 

> solution. 

> 1) fewer gates 

> 2) we will finish the euterpe logic design sooner 
> 

> dickson 
Let's not forget that many of the gates necessary to implement HW 

> icache fills are also needed to implement uncached ifetch from Flash 

> Rom, Cerberus, and dram. 

While it is certainly convenient to have uncached/unbuf f ered ifetch, I still believe it is 
nonessential. We forced it essential some time back by refusing to let the processor 
reset by bootstrapping about 2 hexlets into IBuffer from the reset vector (which is not 
free, but is doable) . 

> 

> The savings from eliminating HW icache fills may not be a great as at 
first 

> glance. 

I have well known ideas about big time savings from tweaking more than the fills. 

Woody is currently looking at a considerable amount of hardware to stage the icache index 

through the instruction queue and issue to the 2 different pipe points where we can do the 

tag check. 

> 

> jeffm 
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From: Graham Y. Mostyn [graham@polyhymnia] 

Sent: Friday, October 07, 1994 5:08 PM 

To: 'abbott@polyhymnia'; 'hoppe^polyhymnia'; 'tbr@polyhymnia'; 'lisarcgpolyhymnia'; 

'gee rt@ poly hymnia'; 'ras@polyhymnia' 
Cc: 'brianl@polyhymnia'; 'brian@polyhymnia'; 'jeffrrKgpolyhymnia'; 'bfox@polyhymnia'; 

'dane@polyhymnia'; , hessam@polyhymnia"; , graham@polyhymnia'; Yich@polyhymnia'; 

'yves@polyhymnia'; 'arya@polyhymnia'; 'fwo@polyhymnia' 
Subject: Verification 


I would like to call a status review and scheduling meeting at 2pm next Wednesday, October 
12, concerning system verification using Ptolemy. There are some verification tools 
needed to close holes that exist. Let's meet in the War Room. 

AGENDA 

- Assess scope of task and estimate of completion on the following: 

1. How shall we run Ptolemy on our database? Capability for Ptolemy to accept database 
information one level above transistors. 

2. Current and voltage support (load/source information) within Ptolemy. 

3. Unix sockets to run Ptolemy, verilog and euterpe simulation in parallel. 

4 . Library development : - C++ training and support 

- bringing and validating new models from 
UC Berkeley 

- model verification (analog celltest) 5. Other issues? 

Thanks - Graham . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisa 

Friday, October 07, 1994 5:24 PM 
'Veena Malwankar* 
'gmo'; 'doi' 

Re: questions about terp assembly 


> How is gdepi (etc) instruction assembled? 

I'm under the assumption that you and gmo will work this one out. 

> How is shuffle instruction specified? In gnu-tools/opcodes/terp-opc . c 

> it says gshufflei uses a single register, but gshufflei from xlu 

> documentation is supposed to operate on register pair. Which is correct? 

Gshufflei has *two* single registers as a source, which are "combined" 
and then treated as a full 128-bit source (ra[63:0] | rb[63:0]). 
The destination, rc, is a register pair. 

> Is there any documentation on assembly language for these new 
instructions? 

Nope. We have needed an assembler reference manual for, say, three years now. The fact 
that you know where terp-opc.c is found, and how to interpret its contents, is as close as 
we get to documenting the assembler syntax. On the plus- side, that file is, by 
definition, up-to-date with respect to the assembler source. 


lisa 
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From: tbr 

Sent: Friday, October 07, 1 994 5:36 PM 

To: 'Jay Tomlinson' 

Cc: 'dickson@aphrodite'; Vo@aphrodite' 

Subject: verilog warning 

Follow Up Flag: Follow up 

Flag Status: Red 


Jay Tomlinson wrote (on Fri Oct 7): 

It is just a missing wire del. I will fix it. 
Jay 

Tim B. Robinson wrote (on Fri Oct 7): 
Verilog is giving me 

Warning! Implicit wire has no fan in [Verilog- 1 WF A] 

"euterpe.v", 325: test_vref 

in the latest BOM. Can you check it out please? 

This wasn't from v2e. *verilog* does not usually give this warning 
unless there is no driver on the net. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Semmelmeyer [mws@clytemnestra3 
Friday, October 07, 1994 6:18 PM 
'Curtis Abbott' 
'euterpe@clytemnestra' 
Re: icache miss 


Abbott wrote: 


> One of the big issues for software-based cache miss handling is 

> getting the information (physical address and protection bits) 

> normally provided by the GTLB. If you do this in software, it will 

> take hundreds of instructions. The hardware could provide it in the 

> exception register. Since PA's are 48b, protection is 16b, and 

> exception register is 64 bits, there are enough. So, this is the 

> hardware change that makes the software overhead possibly tolerable. 

> Is this a problem? 

I am not sure what you intend to do with the existing bits in the exception (status) 
register. Or do you mean the "fail LVA" register and the hardware would store 
physical+prot instead of virtual? 


> Another issue is serializing handling of multiple I cache misses. 

> This isn't really necessary as long as the misses go to different 

> lines, but if hardware doesn't serialize at least these, software 

> must. This adds setup, register save/restores, and 2 atomic ops to 

> the critical path -- something like 16 major cycles of overhead. 
> 

> However, in Euterpe exceptions serialize across the machine. This 

> solves the serialization issue for the handler, at no real cost for 

> the current application. It will degrade performance, however, in a 

> software design (such as Un*x) where tlb miss exceptions are used for 

> page faults. 

I guess you can get away with leaving the exception lock on while waiting for fills from 
DRAM without overrunning deadlines because you intend to have no other exceptions and no 
short deadline code using the cache at all (intercylinder effects) . 


> Lisa's code is at the end of this message. It looks like the startup 

> could be reduced to about 40 major cycles, including the 10 cycles to 

> generate the exception. 

The exception generation is 14-17 cycles. 


> The conclusion is that for I cache miss handling, there are major 

> simplifications (and hence, speedups) for software relative to the 

> general case. There are some extra overheads. The critical path 

> looks something like this: 

> 1. exception taken (15 cycles) 

> 2. save 2 regpairs (6 cycles avg, to sync with store issue 

> restriction) 

The first instruction in the handler will be a load (but not store) slot. 

So the "sync" wait will not be random, and if you can find something that doesn't have to 
wait for the regpair save you can fill in 2 issue slots not usable for the register save. 

> 3 . load or construct exception register & cache tag base addrs (4 
cycles) 

> 4. load saved PC to get VAddr that missed (2 cycles) 5. mask VAddr, 

> construct invalid tag value (2 cycles) 6. store invalid tag (2 cycles) 

> 7. load exception register to get PAddr that missed (2 cycles) 8. 

> convert PAddr to uncacheable VAddr (2 cycles) 

Do you have enough GTLB entries to have ones for uncacheable VAddr s? 

Or do you need them for something else anyway? I am trying to think of a helpful assist 
instruction that would do the loads using the user's virtual address but just force the 
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loads noncacheable. This would save you step 8 and us 48 bits of exception status. 

> 9. load first hexlet of cache line from DRAM (many cycles) ...(do 4 

> hexlets, possibly saving & restoring more regpairs while 
waiting) 

> k. format new VAddr, store to cache tag (2 cycles) 

> k+1. load 2 regpairs (4 cycles) 

You may need to check that the fill data is actually in the I SRAM. 
You may need an assist from the hardware to do this efficiently. 

> k+2 . b.back (7 cycles) 


> - cerb useless 
What did this mean? 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 
Friday, October 07, 1994 6:26 PM 
"Mark Semmelmeyer' 
'euterpe@clytemnestra' 
Re: icache miss 


The bulk of your questions have to do with stuff after Lisa's code. 

These lines last 40 lines of my post -- were supposed to have been deleted before I 
posted. Please ignore them. 

Mark Semmelmeyer wrote (on Fri Oct 7) : 

Abbott wrote : 


> One of the big issues for software -based cache miss handling is 

> getting the information (physical address and protection bits) 

> normally provided by the GTLB . If you do this in software, it will 

> take hundreds of instructions. The hardware could provide it in the 

> exception register. Since PA's are 48b, protection is 16b, and 

> exception register is 64 bits, there are enough. So, this is the 

> hardware change that makes the software overhead possibly tolerable. 

> Is this a problem? 

I am not sure what you intend to do with the existing bits in 
the exception (status) register. Or do you mean the "fail LVA" 
register 

and the hardware would store physical+prot instead of virtual? 
Yes, I meant the fail LVA register. In the icache miss case, the fail LVA is conveniently 
represented in the saved PC. 


> Another issue is serializing handling of multiple I cache misses. 

> This isn't really necessary as long as the misses go to different 

> lines, but if hardware doesn't serialize at least these, software 

> must. This adds setup, register save/restores, and 2 atomic ops to 

> the critical path -- something like 16 major cycles of overhead. 
> 

> However, in Euterpe exceptions serialize across the machine. This 

> solves the serialization issue for the handler, at no real cost for 

> the current application. It will degrade performance, however, in a 

> software design (such as Un*x) where tlb miss exceptions are used for 

> page faults. 

I guess you can get away with leaving the exception lock on while 

waiting for fills from DRAM without overrunning deadlines 

because you intend to have no other exceptions and no short deadline 

code using the cache at all ( intercylinder effects) . 
Right. It's ok for exceptions to be locked out. It's not ok for interrupts to be locked 
out, but they're not. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, October 07, 1994 6:39 PM 
'software-checkins-dist' 
gnu-tools/gas/con fig tc-terp.c 


Update of /p/cvsroot /gnu- tools/gas/conf ig In directory 
calliope : /N/auspex/root /s6/lisa/src/gnu- tools/gas/conf ig 

Modified Files: 
tc- terp . c 
Log Message : 

Wrong mask was being used for recording implicit bit (7th bit of a 7-bit control value) 
for later use in determining opcode. 
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From: Buffalo Chip [chip@rhea] 

Sent: Friday, October 07, 1 994 9:26 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/mc BOM 29.0 initiated by dickson completed @ Fri Oct 7 
19:25:40 PDT 1994 with exit status 0.. chip 
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From: Buffalo Chip [chip@rhea] 

Sent: Friday, October 07, 1994 9:47 PM 

To: 'geert^rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/es BOM 52.0 initiated by dickson completed @ Fri Oct 7 
19:45:15 PDT 1994 with exit status 1.. chip 


lock read: File exists 
all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kurt Warn pier [wampler@thoas] 
Friday, October 07, 1994 10:14 PM 
'geert@ambjorix' 

'hopper@thoas'; 'wampler@thoas' 
Re: Gards help 


Geert writes : 


> in -geert/chip/euterpe/verilog/bsrc/gards . save 

> there is a routed euterpe_geert- iter . 
> 

> There are some problems with busses not routed because of target 
>problems or other problems. 

> 

> Can you look at the routes to investigate how we can make this thing 
>fully route ? It's routed 98%, line-search only, 3400 unconnects. 

Well, I had a quick look at it this evening. I don't see anything that's 
an obvious easy fix. I see several classes of problems: 

1) Many of the unroutes in cdio look like they should be routable I 
suspect we can adjust some knobs on the router and get it to route 
more of these pins . It would however be at the expense of wire 
length, since the only tracks remaining for these connections are far 
out of the way. I believe I would experiment with increasing the 
search depth to perhaps 150 or 200 (in the final pass) . I might also 
increase bestescape to 3 0 or 40. 

2) I see a number of unroutes that look like our old nemesis the pinprotect 
problem. SVR now lists our pinprotect enhancement request as the top 
priority among MicroUnity enhancement requests (but of course it competes 
with all the other enhancement requests from their other customers) . 
Many M1/M2 targets are just covered up by unrelated routing on Metal4 . 

3) The horizontal tracks in the MC <-> ES region appear *very* congested, 
and there is a class of nets that want to pass horizontally through 
this region and can't because the tracks are already 100% filled up. 

I can look at some of these areas with you in more detail on Monday if 
you think it might be helpful . We should also press SVR to provide the 
protectpins enhancement for us . We might even entertain the notion of 
inviting one or more of their senior apps people to have a look at some 
of these problems. While I'm throwing out wild ideas, I understand that 
Kim Stevens is still doing GARDS consulting as well. Maybe we would want 
to consider contracting him to help out with some of this analysis too. 


- Kurt 
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From: Richard Dickson [dickson@gamorra] 
Sent: Friday, October 07, 1994 11:41 PM 
To: , tbr@gamorra'; , woody@gamorra' 
Subject: test_vref 

i put a wire declaration with a dirty bit we problem for thr itags. 

its driven i the euterpe_pads 

bgbbcstm be 1 5 (vrr, vff, vrefl 5); 

i recently wired it to the analog testpoint mux in euterpe. V 
its probably not called out as an output in some verilog file. 

dickson 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Saturday, October 08 , 1 994 1 : 1 5 PM 
To: 'tbr@ambiorix'; 'wampler@ambiorix' 
Subject: more routing info .. 

I tried to route just the I/O nets in euterpe ( all the nets at the 
top level that go between subb locks). 

Of the 12000 nets, 600 did not route and I get a lot of : 

Apparent pin/routing obstruction overlap at grid (4177,9815) 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 

Saturday, October 08, 1994 6:19 PM 

'Kurt Wampler' 

'geert@ambiorix' 

Re: more routing info .. 


Kurt Wampler wrote (on Sat Oct 8) : 
Geert writes : 


> I tried to route just the I/O nets in euterpe ( all the nets at the 
>toplevel that go between subblocks) . 

> 

> Of the 12000 nets, 600 did not route and I get a lot of : 

> 

> Apparent pin/routing obstruction overlap at grid (4177,9815) 

In REDIT, if you go into the "DISPLAY SETUP" menu and change the coordinate 
system to "DF GRID" and click on the button "Command Line Active" (or 
something close to that) , you can then zoom in and in the command line 
window enter "pan 4177 9815" to investigate the geometry at the 
coordinates that the router is reporting obstructions at. 

We do, however, get this message any time we have clock pins on cells 
that don't tie to the global PHI_A2P & PHI_B2P wires. GAROUT sees the 
two targets under the clock wires and gripes about them, even though 
we always have a third exposed target available as well. So, if you 
see clock wires over Metall targets at those coordinates, then that 
is what is happening. It's worth spot-checking one or two just in 
case there is a cell with an obstruction problem. 

We used to see this a lot in the iorate fifos where there are flops clocked from the 
hermes closk. In euterpe, all these cells are now eitehre scioff or scioffdfl6s. I don't 
know if these have multiple targets (they may well have, being derived from the calliope 
xbff cells). I would expect there to be about 120 of these cells at the top level. 


Tim 
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From: John Campbell [solo@abderus] 

Sent: Sunday, October 09, 1994 2:24 PM 

To: 'Geert Rosseel' 

Cc: , geert@abderus'; 'ong@abderus' 

Subject: Re: xbc01dh4s 


as Geert Rosseel was saying 

..The resistor should have been added to the layout. Vikki did that. 

..The resistor should be part of the C01 layout lobe. There should ..be 1 square of MIRES 
layer . 

. .Geert 


The following is the cell i get. maybe my path is wrong. Could you tell me where i 
should be pointing. If i am correct, Aug 19 is the last change. 


find_cell xbc01df4s 
/u/chip/euterpe/proteus/compass/leaf /xbcOldf 4s . ly 
solo@abderus -/test /compass 134 % 11 
/u/chip/euterpe/proteus/compass/leaf /xbcOldf 4s . ly 
-rw-r--r-- 1 chip 1546 Aug 19 20:53 

/u/chip/euterpe/proteus/compass/leaf /xbcOldf 4s . ly 


regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: Buffalo Chip [chip@rhea] 

Sent: Sunday, October 09, 1 994 5:49 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/ctioi BOM 3.0 initiated by dickson completed @ Sun Oct 9 
15:47:56 PDT 1994 with exit status chip 

lock read: File exists 
all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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Subject: 


Sent: 

To: 

Cc: 


From: 


John Campbell [solo@abderus] 
Sunday, October 09, 1994 6:16 PM 
'Geert Rosseel' 

'geert@abderus'; 'ong@abderus' 
Re: xbc01dh4s 


as Geert Rosseel was saying 

..There is a subcell called C01 (somewhere in proteus, maybe not released ???) . 
. .That is used to build the 01 generators and thi scell contains the resistor. 

. .Geert 

/u/chip/euterpe/proteus/compass/layouts/c01. ly 

same as the one in /u/chip/mdunit /proteus sep 19. 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbe@microunity.com 

Monday, October 10, 1994 12:36 AM 

'Craig Hansen' 

'hestia@microunity.com'; 'tbr@microunity.com'; 'wayne@microunity.com'; 
'abbott@microunity.com'; 'graham@microunity.com'; 'jt@microunity.com'; 
'khp@microunity.com'; 'lisar@microunity.com'; 'philip@microunity.com' 
Re: FlashPROM Sockets for initial boards 


On October 7, Craig Hansen wrote: 

>Just to stir the pot a little more: another alternative to changing the 
>package is to incorporate a connector (or board-edge pins) that can 
>access the EE PROM for programming. This would permit keeping the TSOP; 
>Given the Toltec reluctance toward boot ragas, I think the 4 MBit 
>EEPR0M is important. 
> 

>If space is at a premium, this could even be done with a break-off 
>portion of PC card, or use bed- of -nails connection as might be employed 
>for board test. 
> 

>Just for the record, I'd affirm a position that this is unnecessary 
>complexity, as I consider it unlikely that Cerberus would fail to work 
>for boot purposes and still operate properly for system configuration 
>and other essential parts of Euterpe and Calliope. 

>Similarly, given Cerberus, EE PROM shouldn't be an essential part of 
^system bring-up: if the EE PROM interface fails somehow, the rest of 
>Euterpe and Calliope can be fully demonstrated by using the Cerberus 
> interface to replace the EE PROM functionality. 


The difficulty with a EE PROM connector is access with the covers on. If the pcb will 
function for the purpose of programming the EE PROM without EMI integrity, then this should 
work. My position is the same as yours as stated in your third paragraph. Still awaiting 
final resolution on this issue. 


>Regards, 
>Craig 


Regards , 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, (4 08)734-8136 fax 


tbeOmicrounity . com 


Exhibit C7 


Page 167 of 703 


From: 


tbr 


To: 


Sent: 


Subject: 


Monday, October 10, 1994 1:32 AM 
'dickson' 

forwarded message from Buffalo Chip 


Follow Up Flag: Follow up 
Flag Status: Red 

Latest attempt looks to have suuceeded. 

Start of forwarded message 

Return-Path: <chip@gamorra> 

Received: from gamorra.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA1 1697; Sun, 9 Oct 94 23:26:24 PDT 
Received: from localhost by gamorra.microunity.com (8.6.4/muse-sw.2) 

id XAA00436; Sun, 9 Oct 1994 23:29:16 -0700 
Message-Id: <1 994 101 00629. XAA 0043 6@gamoira.microunity.com> 
From: chip@gamorra (Buffalo Chip) 
To: tbr@gamorra 

Subject: output of euterpe/verilog/bsrc/ctioi/.checkoutrc 
Date: Sun, 9 Oct 1994 23:29:16-0700 

The output from euterpe/verilog/bsrc/ctioi/.checkoutrc is 128k, so it is not included 
in this mail message. Instead, check the file 

/n/tmp/chiplog/tbr.gamorra.25499.euterpe-verilog-bsrc-ctioi 

(which is accessible from all machines). This file will disappear in 
about 5 days. 

By the way, the exit status returned by .checkoutrc was 0. 
End of forwarded message 
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From: Mark Hofmann [hopper@tomato] 
Sent: Monday, October 10, 1994 4:54 AM 
To: 'Jay Tomlinson' 

Cc: Vant@tomato'; Tim B. Robinson'; Thomas Laidig'; 'Brian Lee' 
Subject: Re: topt totals vs size totals 

vant writes: 
Jay Tomlinson writes: 

> 

>Dave, 

> 

>I ran 'gmake gards/at-passl.size' and topt produced 
different totals than was in 

>the .size file. Is this expected? If yes, which is correct? 

> 

>topt: 

> Atoms: count atom bjt isrc pld clock 

> BJT Totals: 1295 14290 22497 18817 22050 11630 
>.size file: 

> BJT Totals: 1288 14134 22497 18817 22050 11630 21093fF 

> 

>The files are in /u/woody/chip/euterpe/verilog/bsrc/at/gards. 

> 

>thanks, 
>Jay 

The problem stems from the fact that the program used to generate the .size 
file doesn't seem to know about the high powered xbxor gates (24s and 32s). 

There is an additional warning in the .size file: 

Cells with no stats file entry or not in the design: 
cell type count 

xborl0df32s 2 
xborlldf32s 1 
xborl4df32s 1 
xbor7d£24s 1 
xbor8df24s 1 
xbor9df32s 1 
Unknown Totals: 7 

Topt knows about these and is adding them into the total which explains 
why the atom counts vary. If you want, I can look into this farther, or 
we can wait until monday when Hopper gets back (I think it's his program 
which generates the .size file). 

Thanks, 
Dave 

Hi, 

Dave is right- Topt and Atoms are counting things differently. Topt's cell 
count is correct (and agrees with Atoms' if you add in the 7 cells it does 
not know about). Topt's atom count adds in a guess of the 24s and 
32s cells layouts. The exact info is not available yet (Tom can leafmold 
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supply this?). Both Topt's and Atoms' bjt/isrc/pld numbers are low (because 
counts for this info are all 0 in the stats file). 

The reason that Atoms claims not to know about the 7 cells is because it 
detects a missing or incomplete entry in the stats file. Perhaps we can 
fix this add this data today. 

-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Warren R. Ong [ong@ares] 
Monday, October 10, 1994 11:19 AM 
•John Campbell' 

'geeiKgambiorix'; , geert@abderus'; 'ong@abderus' 
Re: xbc01dh4s 


>From John Campbell . . . 

@ 

@ as Geert Rosseel was saying 

@ . . 

@ . .There is a subcell called C01 (somewhere in proteus, maybe not released ???) . 
@ . .That is used to build the 01 generators and thi scell contains the resistor. 
@ . . 

@ . .Geert 
@ . . 

@ 

@ /u/chip/euterpe/proteus/compass/layouts/c01 . ly 

@ 

@ same as the one in /u/chip/mdunit/proteus sep 19. 

It looks like John's schematic is not picking up the latest R50m schematic. Is there 
something special about releasing a primitive? I thought that it was released. I'll 
check with Derek. 


Warren . 
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Sent: 

To: 

Cc: 


From: 


John Campbell [solo@echidna] 
Monday, October 10, 1994 11:28 AM 


Subject: 


'Warren R. Ong' 
'Geert Rosseel' 
Re: xbc01dh4s 


as Warren R . Ong was saying 

. . >From John Campbell . . . 
. .© 

. .@ as Geert Rosseel was saying 

. .© . . 

. .@ . .There is a subcell called C01 (somewhere in proteus, maybe not released ???) . 

. .© ..That is used to build the 01 generators and thi scell contains the resistor. 

. .0 . . 

. .@ . .Geert 

. .© . . 

. .© 

. ,@ /u/chip/euterpe/proteus/compass/layouts/c01 . ly 
. .@ 

. . @ same as the one in /u/chip/mdunit /proteus sep 19. 

..It looks like John's schematic is not picking up the latest R50m ..schematic. Is there 
something special about releasing a ..primitive? I thought that it was released. I'll 
check with . .Derek. 

. .Warren. 


my interpretation is that the layout is wrong. 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: 
Sent: 
To: 

Subject: 


Jay Tomlinson [woody@melpomene] 
Monday, October 10, 1994 12:18 PM 
'mws@melpomene' 

TRGTEX Exception Added to AT interface. 


Mark, 

I just checked-in euterpe.V and at. This change adds the TRGTEX Exception to the AT 
interface. It is called ATtrgtExXcR13 . currently the wire declare is just above AT. This 
is essentially an OR of all the individual exceptions. 

I am in the process now of releasing a .0 BOM. 


Jay 
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From: Herman Chu [hchu@phobos.microunity.com] 

Sent: Monday, October 10, 1994 2:06 PM 

To: 'boxers@phobos.microunity.com 1 ; 'al@phobos.microunity.com' 

Cc: 'hchu@phobos.microunity.com'; 'hestia@phobos.microunity.com' 

Subject: Thermal Testing of the Second Aluminum Hestia Housing 


The second aluminum housing for the new double exhaust design had been tested for thermal 
performance. Heat loads were applied to simulate euterpe, calliope, and the DC/DC module. 
The power dissipation rates used were 120 watts total for Euterpe/Calliope and 55 watts 
for the DC/DC module. The data will be compared to the first aluminum housing test for 
the single exhaust design, 

which had 120 watts total power to Euterpe /Calliope and only 40 watts to the DC/DC module. 

The results showed that the new design has much better thermal performance even though the 
blower is being bled off from 2 locations. The important results are summarized as 
follows for sea- level: 


Design 
(Exhaust) 

Ambient Temperature 

Average Ca/Eu 
Heat Sink Base 
Temperature 

Average DC /DC 
Heat Sink Base 
Temperature 

Acoustic 

Component Side 

DC/DC Side 

Maximum 

Skin Temperature 
of the Top Cover 


Low Blower Speed 
Old Design New Design 


High Blower Speed 
Old Design New 


(Single 
Exhaust) 


25 C 


52 C 


3 3 dBA 
N/A 

43 C 


(Dual 
(Exhaust) 


60 C 


70 C 


3 6 dBA 
35 dBA 

35 C 


{Single 
Exhaust) 


70 C 


63 C 


50 dBA 
N/A 

57 C 


(Dual 


56 C 


65 C 


48 dBA 
4 9 dBA 

49 C 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, October 10, 1994 2:12 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. h v_mem.c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 

memory . h v_mem . c 
Log Message: 

If bit 47 is set, virtual != physical exception iff va[15:6] != pa [15: 6] . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kurt Wampler [wampler@thoas] 
Monday, October 10, 1994 2:19 PM 
'geert@ghidra' 
'wampler@thoas' 
Re: Toplevel run 


>Hi Kurt, 
> 

> All the data lives in : 
> 

> -geert/chip/euterpe/verilog/bsrc/gards . save 
> 

> Geert 


OK - thanks. Preliminary analysis: 

1) ordered. net s . top contains some 47 0 0 nets which do not appear in the dff 
examples: ADIN_V, AUBASE634 7R2<48 : 63 > etc. Perhaps these are one-pin 
nets that have been pruned away? I've verified that they don't exist 
in the dff, so that explains why GAROUT is warning about them. 

2) The pin/obstruction overlaps that GAROUT is warning about all seem to 
arise from Metal3 targets sitting on top of a field of Metal2 . Since 
the first pass of routing is a Metal2/3 route, it can't get to those 
targets on Metal2 because of the field Metal2 under them. They look 
routable on M3/M4, though. The cell TTLE2TEU is one of the cells, and 
CLOCKBIAS is the other. 

3) ordered. all .nets contains 16,990 more nets than the dff. 


- Kurt 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, October 10, 1994 3:02 PM 
'Jeff Marr' 

Re: dcache access causes core dump 


> Running dcacheeasyl . exe on terp I get a core dump . 

This core dump will happen for awhile, until the simulator is changed to allow pre-loading 
of the cache. I'll let you know when I think it should work. FYI, once that *does* work, 
you won't want to specify the dbuffer size as 32k -- that gives you a dcache of 16k *and* 
a dbuffer of 32k -- unless you have a . onchip_data section of 48k intended to be pre- 
loaded into dbuffer and dcache. The defaults in the simulator 
(16k, 16k) are probably what you want. 

Separately, though, I noticed a coupla bugs: 

- You are writing a mask of all- zeros to the local tlb; 
this should be mask of all-ones. 

- After initializing the first few global tlb entries that you 
need, you initialize the remaining entries with the same mask 
and match (0x2 0 0000000000) . This is a bad idea; you must 
never have more than one tlb entry that can match the same 
virtual address. Every entry should have something which can 
never match, like a mask of 0 and a match of non-zero. 


lisa 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 10, 1994 3:57 PM 

To: 'geert^rhea* 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/gt BOM 52.0 initiated by age completed @ Mon Oct 10 13:51:45 
PDT 1994 with exit status 0.. chip 
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From: vant [vanthof@hestia] 

Sent: Monday, October 1 0, 1 994 4:34 PM 

To: 'Ken Hsieh' 

Cc: 'hopper@tomato'; Vant@rimulac'; 'tbr@rimulac' 
Subject: Re: Swap on dracula machines 

Ken Hsieh writes: 

> 
> 

>There are two ways to add more space for swap area. 

>1) repartition the disk and make swap partation bigger. 

>2) add "swap file" in one or more partations which have the space 

> 

>In this moment, I'd like to use (2) to add more swap space for the 
>dracula machines. 

> 

>Now, 1 need you to tell me where should I get the space. 

>In order to make a 2,1GB of swap space,I will need 

>0.5GB on cyclops 

>0. 4GB on tomato and 

>0.3GB on mothra. 

> 

> 

>cyclops 
> 

>Filesystem kbytes used avail capacity Mounted on 

>/dev/sd2g 1629014 850178 615935 58% /si 

>/dev/sd3g 1629014 605953 860160 41% /s2 

Well, /s2 would be the choice of these two disks, but the best would be to 
add another disk. 


>tomato 


>Filesystem kbytes used avail capacity Mounted on 

>/dev/sd2g 1629014 629770 982954 39% /si 

>/dev/sd3g 1629014 1080063 532661 67% /s2 

>/dev/sd3h 1042702 787233 245042 76% /s3 


I've cleaned up some data on /s3, so that would be the best disk on tomato. 


>mothra 
> 

>Filesystem kbytes used avail capacity Mounted on 

>/dev/sd2g 1962485 916321 849916 52% /s2 

>/dev/sd3g 1962485 194865 1571372 11% /s3 

>/dev/sdlg 819286 3477 733881 0% /s4 


/s4 is the best disk here. 


Ken, On all of the dracula machines, it would be nice to have the disks 


Exhibit C7 


Page 179 of 703 


reformatted so that no extra space is allocated for the OS. Unix typically 
preserves 10% of the disk for itself, and for dracula machines this is 
a desperately needed amount of space. In addition, Mark also mentioned that 
there will be small numbers of large files, so having the disk set up with 
small amounts of inodes and larger blocks would also help. 

We will have to schedule the disk reformating around various tapeouts, so that 
will be hard, but in the meantime, if the swap partitions could be added, 
that would help. 

Thanks, 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisa 

Monday, October 10, 1994 4:39 PM 

'Jeff Man" 

'gmo' 

Re: dcache access causes core dump 


> Ack. Thanks for 


catching the gtlb init bug. 


Sure. 


> P.S. For dcache and icache preload to work, the onchip data and text 
sections 

> need to be able to be up to 3 2K even when I specify the cache config 

> as 16/16, or whatever. 

I know. That's exactly what I was saying. 

> Actually, I would be nice for the cache config bits in cerberus to 

> work, 
too . 

Yep, but it isn't *terribly* necessary. When you specify the cache and buffer size on the 
command line (or leave defaults as is at 16/16) , you are doing the same thing as setting 
the cerberus bits would do, except that we also allow you to magically increase the size 
of things. If you really want all buffer and no cache, " - -dcache- size Ok --dbuf f er-size 
32k" would be the way to specify it. (I know it doesn't work, but we can make it work for 
completeness sake, though *not* specifying the dcache size and just specifying " --dbuf f er- 
size 32k" works fine as long as you don't try to do a cached load/store.) But that 
doesn't mean you could then *change* the cache configuration and have the second half of 
the dbuffer magically transformed into cache. I'm under the impression that a reset will 
be required after changing the cache configuration, which, I think, gives you no guarantee 
about the contents of on-chip memory. So you'll have to configure it, reset, and *then* 
load the contents. (Of coure, iff the hardware will let you dynamically change the cache 
configuration, please let me know, and then I can also make *that* work in the 


At any rate, specifying the cache configuration as 16/16 and then loading 32k at the 
address of the start of dbuffer should put the first 16k into dbuffer and the second 16k 
into cache. That is, regardless of the configuration, cache *and* buffer can be directly 
read/written at their appropriate memory-mapped addresses . Whether or not you have any 
cached translations set up and in use will be what determines whether or not the dcache is 
accessed via an indirect load or store. 


simulator . ) 


lisa 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 
Monday, October 10, 1994 4:49 PM 
'geert@rhea' 
pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/ctioi BOM 6.0 initiated by dickson completed @ Mon Oct 10 
14:43:23 PDT 1994 with exit status 0.. chip 

all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 
Monday, October 10, 1994 5:08 PM 
'geert@rhea' 
pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cj BOM 62.0 initiated by dickson completed @ Mon Oct 10 
15:06:23 PDT 1994 with exit status 1.. chip 

all ports busy- 
all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: Jeff Marr [jeffm@kephalos] 

Sent: Monday, October 10, 1994 5:32 PM 

To: 'euterpe@kephalos' 

Subject: Euterpe logic clear, reset, and machine check 


Well, I asked how this works, and. . . . 

Looking at these things from a FUNCTIONAL point of view only, here is my (likely faulty) 
understanding : 

LOGIC CLEAR 

Invoked by setting the clear bit in cerberus . 
Sends a reset strobe to the ECL logic. 

Contents of buffer, tlb, register file, etc. not guaranteed. 

Causes deferred write to cerberus registers. 

Cerberus registers not otherwise touched, except for 
clear complete bit in register 7. <-- See below. 

If the dram interface has been "protected" by setting the 
output set high bit in cerberus register 10 before the 
clear is invoked, and the bit is subsequently cleared 
after the clear completes, the dram contents are 
untouched by the clear. 

Each cylinder starts fetching instructions from the start 
vector address at the end of the clear. 

NOTE: WRT cache configuration, a logic clear is recommended whenever 
the cache configuration is changed. When ini tally configuring the 
cache, i.e. before memory management is enabled, a logic clear is 
NOT required. Per billz. 

RESET 

Invoked by grounding SD line, or by writing the reset bit, or 
by overtemp, or by double machine check error. 

Resets cerberus registers to default states. <-- See below. 

Sends a reset strobe to the ECL logic. 

Contents of buffer, tlb, register file, etc. wiped. 

Dram contents not guaranteed. 

Each cylinder starts fetching instructions from the start 
vector address at the end of the clear. 

Reset cause discernable from cerberus registers 6 and 7. 
MACHINE CHECK 

Invoked by HW error. 

Sends a reset strobe to the ECL logic. 

Contents of buffer, tlb, register file, etc. not guarenteed. 
Cerberus registers not touched, except for machine check 
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cause information in register 7. See below. 

Dram contents may have some damage - the reset strobe will 
cause interface signals to jump around a bit. <--See below. 

Each cylinder starts fetching instructions from the start 
vector address at the end of the clear. 


Comments : 

I know I have skipped a lot of the finer points, but I wanted to 
include enough to make the following points: 

1. Memory management has to be turned off in all three cases, but 
a clear or machine check currently leaves that bit untouched. 

2. It also may be a good idea to disable the Hermes channels at the 
beginning of a reset, clear, or machine check sequence. Are there 
cerberus bits that should be set /cleared? 

3 . Are the default cerberus register states loaded during an 
overtemp reset different than the defaults in other reset 
conditions? 

The default knob settings are mid- range, I think, but 
there is a provision to override that from the pins . 
The default clock state is to bypass - so the SOFA 
clock is equal to the 54MHz ref in? The default 
hermes clock is 2X refin? 

4. What is the exposure of possibly clobbering some dram contents 
on a machine check? Is it possible to automatically set the 
output set high bit in cerberus register 10 at the beginning of 

a clear or machine check? 


Comments? 


jeffm 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 
Monday, October 10, 1994 5:33 PM 
'geert@rhea' 
pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/ctioi BOM 7.0 initiated by dickson completed @ Mon Oct 10 
15:26:47 PDT 1994 with exit status 0.. chip 

all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports, busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Rich McCauley [rich@pegasus] 
Monday, October 10, 1994 6:34 PM 
'jeffm@kephalos' 
'euterpe@pegasus' 

Re: Euterpe logic clear, reset, and machine check 


Regarding the following point/ I think the default for the Hermes should be such that it 
is 27MHz. That is, the divisor should be 3, 4, or 5 and the pll bypassed. When the divisor 
is 3,4,5 , the divide by 2 is activated. This way, the sofa and Hermes clocks are 
processing data at the same rate. 


3 . Are the default cerberus register states loaded during an 
overtemp reset different than the defaults in other reset 
conditions? 

The default knob settings are mid- range, I think, but 
there is a provision to override that from the pins. 
The default clock state is to bypass - so the SOFA 
clock is equal to the 54MHz ref in? The default 
hermes clock is 2X refin? 


rich 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 10, 1994 6:36 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cj BOM 63.0 initiated by dickson completed @ Mon Oct 10 
16:35:30 PDT 1994 with exit status 1.. chip 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Monday, October 10, 1994 8:01 PM 
'fambro'; 'guarino' 
Re: reg-time 


On Oct 10, 4:54pm, Loretta Guarino wrote: 

> Subject: reg-time 

> Does either of you know why reg-time seems to be printing out its 

> command twice? 


> 
> 
> 
> 
> 

Development test mode 
oc- audio 

oc-audio: PASSED 


> 
> 
> 

"terp -q --ibuffer 32k --dbuffer 
will run for 1 hour(s) 0 minute (s) 

3 2k . /oc-audio_2 .exe" 
or for 1 iteration (s) 

1 V V II 1 

> 
> 
> 

"terp -q --ibuffer 32k --dbuffer 
will run for 1 hour(s) 0 minute (s) 

32k . /oc-audio_2 . exe" 
or for 1 iteration (s) 

> 
> 

1 iteration (s) achieved in 0.004 7 

hour ( s ) . 


+++++++++++++++++++++++++++++++++++++++++++++++++++++ 

+++++ 

> oc-audio PASSED, Output matches reference 
> 

>-- End of excerpt from Loretta Guarino 
This isn't coming from reg-time. 

The first echo "oc-audio" is printed by the accept. reg script. The second one is printed 
by terp, presumably it's part of the oc-audio_2.exe code. 

Gregg 


Gregg Kellogg 
gregg@microunity . com 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Monday, October 10, 1994 8:28 PM 
'tbe@MicroUnity.com' 

'al'; 'glen'; 'graham'; 'hestia'; 'jt'; 'noel'; 'philip' 
Design change affects front panel pcb 


Follow Up Flag: Foliow up 
Flag Status: Red 

tbe@MicroUnity.com wrote (on Mon Oct 10): 

The front panel pcb as currently layed out is affected by the design 
revision from bottom air inlet to top air inlet. This revision, which 
eliminates the hole in the main pcb, as well as (potentially) the front 
panel keypads, and also eliminates the need to run the fan power through 
the front panel pcb to get to the fan. The ID related design changes make 
it desirable to change the layout as well. 

Another issue that has come up is the number of and positioning of the 
7-segment LEDs. I believe that there should be a 3:2 arrangement of LEDs 
relative to the colon LEDs, so that the channel display up to three places 
is not asymmetrically arranged due to the colon position. The time display 
would use the 4 right most LEDs. There is room for 5 LEDs in the revised 
design, and I'd like to proceed if this sounds agreeable to all. Let's 
discuss at the netlist meeting and on Hestia. 

We can handle a fifth full digit with the euterpe interface, but if we 
need to retain the colon and the am/pm then there will have to be some 
overlap (ie some segments in the new digit would not be available). 

I appreciate the aesthetics, but I question the justification for 
adding cost. My understanding of the purposes of the display are 

1 . Accurate clock, derviced from a signal on the cable. 

2. Diagnostics. 

Neither of these require the additional digit. 

Given there will be a menu based navigator on screen, I really don't 
see why the channel number needs to be displayed normally on the LEDs; 
it should be on. Indeed, given the size and brightness of the LEDs, 
many people might want to turn them off altogether so they aren't a 
visual distraction near the screen. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 10, 1994 8:28 PM 
'tbe@microunity.com' 

'al@aphrodite'; 'glen@aphrodite'; 'graham@aphrodite'; 'hestia@aphrodite'; 'jt@aphrodite'; 
'noel@aphrodite'; 'philip@aphrodite' 
Design change affects front panel pcb 


tbe@MicroUnity.com wrote (on Mori Oct 10): 

! 

The front panel pcb as currently layed out is affected by the design 
revision from bottom air inlet to top air inlet. This revision, which 
eliminates the hole in the main pcb, as well as (potentially) the front 
panel keypads, and also eliminates the need to run the fan power through 
the front panel pcb to get to the fan. The ID related design changes make 
it desirable to change the layout as well. 

Another issue that has come up is the number of and positioning of the i. 

7 -segment LEDs . I believe that there should be a 3:2 arrangement of LEDs 

relative to the colon LEDs, so that the channel display up to three places 

is not asymmetrically arranged due to the colon position. The time display 

would use the 4 right most LEDs. There is room for 5 LEDs in the revised 

design, and I'd like to proceed if this sounds agreeable to all. Let's 

discuss at the netlist meeting and on Hestia. 

We can handle a fifth full digit with the euterpe interface, but if we need to retain the 
colon and the am/pm then there will have to be some overlap (ie some segments in the new 
digit would not be available) . 

I appreciate the aesthetics, but I question the justification for adding cost. My 
understanding of the purposes of the display are 

1. Accurate clock, derviced from a signal on the cable. 

2 . Diagnostics . 

Neither of these require the additional digit. 

Given there will be a menu based navigator on screen, I really don't see why the channel 

number needs to be displayed normally on the LEDs ; it should be on. Indeed, given the 

size and brightness of the LEDs, many people might want to turn them off altogether so j 

they aren't a visual distraction near the screen. j, 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 10, 1994 11:40 PM 
'hestia^aphrodite' 

'pmayer@aphrodite'; 'bfox@aphrodite'; 'yves@aphrodite'; 'woody@aphrodite'; 'tbr@aphrodite'; 

'ras@aphrodite' 

Netlist Meeting actions 


1. tbe confirmed that vias (including VDD power) are allowed under the clamp (which has an 
insulating finish) provided they are covered in solder mask. The vias in the main GND pad 
under the space transformer must not be covered in solder mask. 

Action - pmayer to check we have correct via types in these locations. 


2. There are some pin swaps pending in the RP section. This needs a source netlist change 
and an ECO into into PCAD 

Action - b fox/ woody to amend netlist 


3 . The current plot shows some of the VDD connections to the analog 
sections on Calliope daisy chained. These need wider traces inside 
the padring and the lowest inductance path to the decoupling caps . 

Action - yves/bfox to work with pmayer to improve these 


4. Some RF traces from Calliope need better isolation. One approach is to fanout the 
traces right from the padring and introduce additional lines with frequent vias to ground 
to isolate differential pairs. 

Action - bfox to supervise layout changes to add these. 


5. Philip confirmed it is OK to use a 10 mil SMT pad to via spacing, provided we have a 
soldermask barrier over the trace. This is necessary for low inductance decoupling and in 
certain places in the RF sections. 


6. The issue of having traces wider than the pads was discussed. This is a potential 
reliability problem because without a thermal barrier there is a possibility of cold 
soldered joints. Bfox needs to be able to do this in the RF section based on experience 
from characterizing the bandsplit filter board. However, the 08 05 pads are large enough 
that a 50 ohm trace can run in directly without being wider than the pad so the total 
number of places where this is needed should be small. It was considered more important 
for prototypes to have the best electrical performance and to compensate with improved 
inspection on known violations. 


7. A decision has been taken to use a reflow process for main board assembly. This is 
because there are some SMT components which are too tall to be compatible with the wave 
process. It was still considered good practice to remain with the 40 mil pad spacing. 


8 . There is a need to be able to program the Euterpe Cerberus address for bringup and 
initial program loading before the flash ROM is programmed. A jumper is considered 
undesirable. Wayne would like a signal bringing to the expansion connector, so this can 
be controlled with the box assembled. We will do this. 

Also on the expansion connector the question was raised if we should have a power relay 
control for the expansion box. No decision was taken. 
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tbr pointed out that another deficiency may be the lack of a reference clock output on the 
expansion connector. 

Action - woody to add this connection to the netlist. 

tbr to post to hestia on the power control and reference 
clock issues to open discussion to a wider group. 


9. In discussing the possibility of routing traces under the die on the top side of the 
board, the question was asked about what assumption was made by ras in modeling the tab 
frame performance. 

It 1 s possible we may need an extended ground plane on the top surface under the whole TAB 
which would preclude the routing of traces there. 

Action - ras to comment on routing restrictions under the TAB frame. 


10. The bandsplit filter daughter cards will be rotated 90 deg. This improves the 
connections to Calliope and prevents crossover of the Rx and Tx lines. 

Action - bfox to communicate requirements to pmayer. 


11. As a result of the fan position change, tbe needs a redesign of the front panel board. 
We will no longer need to carry the fan power through the front panel board. The 
connector pin assignment could be changed as part of this redesign, but tbr felt we should 
not change the assignment unless we find it impossible to route the main board with the 
existing connections. This will keep the second rev of the front panel out of the 
critical path because we would be able to hook up the old version on a longer flex cable 
outside the box for the prototypes. We will schedule a new rev of the front panel after 
the rework of the bandsplit filter board. 

Tim 
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From: 


tbr 


To: 

Subject: 


Sent: 


Tuesday, October 11, 1994 6:16 AM 

'woody' 

Help! X's 


Follow Up Flag: Follow up 
Flag Status: Red 

I have been trying to get a new top level BOM for geert to pick up all 
the latest routing. The machine goes to X after the first 
instruction. I need to diff everything I picked up, but the main 
substantial change was lopping off 16 high order bits from the tags I 
thought. 

Can you take a look in the dump file in ~tbr/euterpe/bsrc please and 
see if you can spot anything obvious? 


Tim 
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From: tbr 

Sent: Tuesday, October 1 1, 1994 12:11 PM 

To: 'doi' 

Subject: sick-oh request (urgent really) 

Follow Up Flag: Follow up 
Flag Status: Red 


I need help getting out a BOM that deletes an obsolete directory. 1 
get: 

mkbom: The following is found in the repository (and the most recent BOM), but not locally: 
mkbom: 

mkbom: Directories : ctio 
mkbom: 

mkbom: Error: Local directory is out-of-date with respect to the repository. 
Problems with mkbom - return code 1 

Unable to release /n/auspex/sl5/tbr/euterpe/verilog/bsrc/BOM 

It's in the latest BOM because billz had the same problem and punted 
by leaving it in. 

Tim 
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Sent: 


To: 


Subject: 


From: 


tbr 

Tuesday, October 11, 1994 1:00 PM 

Vanthof 

pest 


Follow Up Flag: Follow up 
Flag Status: Red 


Seems to be dumping again on an EOF: 
path -> xbhrdh4s 6.0 1:3 xbhrdh24s 

Warning! Cycle time exceeded by 42.47ps using cycle time of 1500.00 for Iteration 1 
Path After Optimization using cycle time of 1500.00: 

Instl (xbhrdh4s4S) Oport: Q_D0PH IntDel: 109.10 net: Net 1 swg: dh delay: 1260. 87ps RC delay: 
190.09ps Ids: 3 pcap: 24.03ff cap: 624.03ff (ext) m21en: 0.00 m31en: 6000.00 m41en: 0.00 

Lastlnst (xbhrdh24s 24S) Iport: SETUP IntDel: 172.50 

Time through Path: 1542.47 

path -> A D 

Segmentation fault (core dumped) 
tbr@gamorra ~/euterpe/verilog/bsrc/xlu 428 % 
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From: Gregg Kellogg [gregg@hts.microunity.com] 

Sent: Tuesday, October 1 1 , 1 994 1 :55 PM 

To: 'Guillermo A. Loyola'; 'Scott Furman' 

Cc: 'brendan@bilbo' 

Subject: Re: Accessing stable tools. 


On Oct 11, 11:58am, Guillermo A. Loyola wrote: 

> Subject: Re: Accessing stable tools. 

> From gregg@hts Tue Oct 11 11:52:26 1994 
> 

> To take Scott's method a bit further: 
> 

> INSTALL_BASE = $ { HOME } / $ { HOSTTYPE } - Ob j 

> USE_INSTALL_BASE = link 

> MUSEROOT = /a/soft /stb 

> export MUSEROOT 

> PATH := $ { INSTALL_BASE } /bin : $ { MUSEROOT } /bin : $ { PATH } 
> 

> This will execute private versions of the tools if they exist and 
doesn' t 

> depend on my absolute home-directory path or machine type. 
> 

> Except you're setting INSTAXjL_BASE to what seems like an area for host 
binaries 

> which is probably not where you want to install terp executables when 
you say 

> "gmake install" in your stb tree. 
> 

> Gmo . 


>-- End of excerpt from Guillermo A. Loyola 

The motivation for doing this is that when host executables are created they should go 
into the appropriate architectural directory. We would have to have different macros, 
such as INS TALL_BASE_HO S T and INS TALL_BAS E_TER P to keep these things distinct. 


Gregg Kellogg 
greggOmicrounity . com 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Jay Tomlinson [woody@luckboy] 
Tuesday, October 1 1 , 1994 2:45 PM 
Tim B. Robinson' 
, hestia@aphrodite , 
Netlist Meeting actions 


Tim B. Robinson wrote {on Mon Oct 10) : 

8 . There is a need to be able to program the Euterpe Cerberus address 
for bringup and initial program loading before the flash ROM is 
programmed. A jumper is considered undesirable. Wayne would like a 
signal bringing to the expansion connector, so this can be controlled 
with the box assembled. We will do this. 

Also on the expansion connector the question was raised if we should 
have a power relay control for the expansion box. No decision was 
taken. 

tbr pointed out that another deficiency may be the lack of a reference 
clock output on the expansion connector. 

Action - woody to add this connection to the netlist. 
Done. I added euterpe cerberus address pin 3 to the connector. I also move the remaining 
unused pins to the other side of the connector to make room for any of these other ideas. 
There are 5 unused pins left over. 


tbr to post to hestia on the power control and reference 
clock issues to open discussion to a wider group. 


Jay 
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vant [vanthof@hestia] 
Tuesday, October 11, 1994 3:40 PM 
Tim B. Robinson' 
, vanthof@aphrodite' 
Re: pest 

Tim B. Robinson writes: 

> 
> 

>Seems to be dumping again on an EOF: 

> 

>path -> xbhrdh4s 6.0 1:3 xbhrdh24s 

> 

>path -> A D 

> 

>Segmentation fault (core dumped) 
>tbr@gamorra ~/euterpe/verilog/bsrc/xlu 428 % 


I forgot to look at that I'm not sure if I can fix it since I'm using 
the libraries from gcc, but I'll certainly give it a try. 

Thanks for the reminder. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (mi) All kids love Log! #incluce <std_disclaim.h> 


! 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Gregg Kellogg [gregg@hts.microunity.com] 
Tuesday, October 11,1 994 3:40 PM 
'Brendan Eich' 
'fur@atm' 

Re: PCR recovery notes 


In order to properly synchronize our internal clock with the PCR 
recieveci on (typically) the highest rate elementary stream of an 
MPEG- 2 transport stream. 

(Need a verb here ! ; - ) 

Sorry, incomplete sentence. I re-wrote it as follows: 

The MPEG- 2 encoder maintains a System Time Clock. Samples of 
this clock are sent in the Transport stream so that the decoder 
can properly synchronize it's internal clock to that of the encoder. 
These samples are sent as a Program Clock Reference field (PCR) on 
one of the elementary streams associated with the transport stream, 
so that the PCR is shared among all elementary streams. 

The MPEG-2 System Clock Frequency is 27Mhz +- 1.35Khz. At start up, 
timing parameters are initizlized based on a 27Mhz clock (1 tick 
every 
37 ns) . 

I think I know what you mean, but just to be sure: the specific timing 
parameters are scale and offset, and nominal scale is some tractable 
form 

of the ratio (terp- cycle -period / 27MHz-clock-period) . 

Maybe the thing to emphasize here, without diving into the details, is 
that 

| the nominal parameters are computed in uncorrected local time units 
assuming 

| synchronized clocks. 

1 

| Mention offset being set to one worst -case video frame period, which 

| is a compiled- in constant and also determines the video input buffer size? 


This should have read "(37ns * NS_PER_CYCLE ticks)." The offset cannot be determined until 
a PCR is recieved. Until further PCR values are received, it is assumed that the 
transmitter and decoder clocks are synchronized. 

If a PTS is received before a PCR, a default PCR value is obtained by subtracting on frame 
period (@ 60Khz) from the PTS and using the built-in worst case video frame period. 

We don't actually take a local 

timestamp value until the entire packet has been Reed- Solomon decoded. 
The PCR is identified with the timestamp recorded in the RS packet 
containing the timestamp, so clocking is somewhat less accurate than 
that specified in the MPEG-2 Specification) . 

Right -- is this a problem? 

Probably not, but as the standard makes it clear what these units are, I thought it 
reasonable to spell out that we're ignoring this. 

There's another software-ish anomaly commented by XXXs in mpeg2-in.c: 

we don't pass the last PCR upstairs for a duplicate packet. This is 

not a big deal -- I don't expect dups in any cable network any time soon! 

| PCR recovery is accomplished by keeping track of the timestamps 
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associated with the last N PCRs recived. The ratio of the 
difference between the first and last of these PCRs and their 
associated timestamp values can then be used as a scaling factor in 
determining some future time relative to the PCR (typically a PTS) . 

Just the scale function is needed for PTS interpolation, but don't we 
want 

| to add offset when the unpacker computes an LPTS and inserts it into 
I the video bitstream, or makes it available to the audio decoder? 

I think that the following paragraph describes this sufficiently: 

By scaling the 

differnece between the PTS and the last PCR with this factor a local 
timestamp delta from the timestamp of the last PCR can be derived. 
The value N must be large enough to negate any jitter in the system. 

This gets into filtering, where N is not the only parameter -- the way 
the past PCRs are averaged or convolved, etc., matters. Without 
diving into PLL filter design, perhaps it's best to try the simplest 
approach first: keep track of only the last PCR, notice saturation, 
and use (clamped (PCR - oldPCR) / delta_t) as the scale. 

I realize that my mechanism is simplistic, but it should converge. Let's talk about this 
some more . 

Question: What happens if a PTS is received before the first PCR? 
This seems like an error condition, but could easily arise. Does 
the system need to wait to see a PCR before the MPEG stream can be 
processed? 

I don't see why the system couldn't localize the PTS using the nominal 
scale and offset, assuming (hah!) that its +-500ppm clock miraculously 
matches the head-end's (alleged by the standard) 50ppm clock, and then 
adapting as PCRs come in. 

Using the worst -case video frame period, or just a tick version of 60Hz should work okay. 

Thanks , 

Gregg 
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From: Buffalo Chip [chip@rhea] 

Sent: Tuesday, October 11,1 994 5:23 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/lt BOM 61.0 initiated by age completed @ Tue Oct 11 15:17:46 
PDT 1994 with exit status 0.. chip 
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From: Buffalo Chip [chip@rhea] 

Sent: Tuesday, October 11, 1994 5:57 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/nb BOM 71.0 initiated by age completed @ Tue Oct 11 15:52:20 
PDT 1994 with exit status 1. . chip 
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From: tbr 

Sent: Tuesday, October 1 1 , 1 994 6:20 PM 

To: Vant' 

Cc: Vanthof@aphrodite' 

Subject: Re: pest 

Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Tue Oct 1 1): 

Tim B. Robinson writes: 

> 
> 

> Seems to be dumping again on an EOF: 

> 

>path -> xbhrdh4s 6.0 1:3 xbhrdh24s 

> 

>path -> A D 

> 

Segmentation fault (core dumped) 
>tbr@gamorra ~/euterpe/verilog/bsrc/xlu 428 % 

> 

I forgot to look at that. I'm not sure if I can fix it since I'm using 
the libraries from gcc, but I'll certainly give it a try. 

Thanks for the reminder. 

No problem. I was assuming it was a new problem. 

Tim 
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From: lisa 

Sent: Tuesday, October 11, 1994 7:17 PM 

To: 'Derek Iverson' 

Subject: Re: ealms instruction 


> In a meeting I had today with lisar and veena they told me that the 

> ealms instruction has been made obsolete. Should this entry in 

> terp-opc.c have a status of ST_OLD? 

It does. Are you looking at an up-to-date table? 
lisa 
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From: Fred Obermeier [fwo@pelagon] 
Sent: Tuesday, October 1 1 , 1 994 7:53 PM 
To: 'tbr@pelagon' 
Cc: 'fwo@pelagon' 
Subject: 90p and m input. 

Tim, 

The 90p and m qualifiers can be found at: 
Range qualifier is not compatible with mpv 90: 
Found 1 different p- values: 90 
Found 1 different p- range values: m 
instance path : top. crrc val urq_ 1 2 1 
cellname path: top.crrcvalurq_121 
leaf connections: 

instance path: top.xcr.x88p_l .x5p_l .xl21xl3p_l.xl5p_l.rb2_ad90p!56v 
cellname path: top.cr .cr3a .cr3pgsas0.cr3pgsa .crgsa .saout_ad90p 15 6v 
instance path : top. xrgrgcrurcvaluhrru57 .crrcvalurq_ 1 2 1 
cellname path: top.xbffdh2s .d0_admph 

Range qualifier is not compatible with mpv 90: 

Found 1 different p- values: 90 

Found 1 different p- range values: m 

instance path : top. err c valurq_n_ 1 2 1 

cellname path: top.crrcvalurq__n_121 
leaf connections: 

instance path: top.xcr.x88p_l .x5p_l .xl21xl3p_l.xl5p_l.rb2_and90pl56v 
cellname path: top.cr .cr3a .cr3pgsas0.cr3pgsa .crgsa .saout_and90pl 

56v 

instance path: top.xrgrgcrurcvaluhrru57 .crrcvalurq_n_l 2 1 
cellname path: top.xbffdh2s ,d0 andmph 

Csyn results from the old netlist can be _temporarily_ found in 
/u/fwo/tbr/fail l/staypuft/tbr_euterpe-passl xsyn 

I hope the releasebom of tools/src/erc to completes sometime soon. 
It's been running for about an hour now. 

Fred. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, October 1 1 , 1994 8:1 1 PM 
'software-checkins-dist' 
gnu-tools/sim/terp decode.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
decode . c 
Log Message: 

Check itag detail and coherent bits, if REALLY_ACCURATE_SIMULATION. 
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From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Tuesday, October 11, 1994 10:24 PM 
'torn 1 ; 'solo' 

'geert'; Vanthof ; 'hopper' 
cannot compile scsynchll 


Follow Up Flag: Follow up 
Flag Status: Red 


I am unable to get a top level LVS netlist compile becuase of a 
problem with the scsynchll cell. Here's what ged21vs is saying: 


<lnk>#l ERROR(145): Pin name does not exist 
Drawing: "SCSYNCHLL". SPICE. 1.1 

No parameters 
Body: "BJT" (Path="6P") 
Unfound pin: "Q_AD0PF" 

Drawing: "TBRJ6UTERPE PAS SI ".SPICE. 1 . 1 

No parameters 
Body: "SCSYNCHLL" (Path="156P") 
Pins of the body: 

"PHIA2P" 

"PHI_B2P" 

"VII" 

"VRR"<0> 

"VRR"<1> 

"VRR"<2> 

"D0AND0PF" 

"Q_A0PF" 

"D0_AD0PF" 

"Q_AN0PF" 


<Ink>#2 ERROR(145): Pin name does not exist 
Drawing: "SCSYNCHLL ".SPICE. 1.1 

No parameters 
Body: "BJT" (Path="7P") 
Unfound pin: "Q ANDOPF" 

Drawing: "TBR_EUTERPE_P A SS 1 ".SPICE. 1 . 1 

No parameters 
Body: "SCSYNCHLL" (Path="156P") 

As far as I can tell my local copies of the schematic for this cell 
and the verilog models used to make the initial netlist are up to 
date. 


Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Tuesday, October 1 1 , 1 994 1 0:24 PM 

To: 'tom@aphrodite'; 'solo@aphrodite' 

Cc: 'geert@aphrodite'; Vanthof ©aphrodite'; 'hopper@aphrodite' 

Subject: cannot compile scsynchll 


I am unable to get a top level LVS net list compile becuase of a problem with the scsynchll 
cell. Here's what ged21vs is saying: 


<lnk>#l ERROR (145) : Pin name does not exist 
Drawing: " SCSYNCHLL " . SPICE .1.1 

No parameters 
Body: "BJT" (Path="6P") 
Unfound pin: ,, Q_AD0PF" 

Drawing : " TBR_EUTERPE_PASS1 " . SPICE .1.1 

No parameters 
Body: " SCSYNCHLL " ( Path= " 156P" ) 
Pins of the body: 

" PHI_A2P" 

" PHI_B2P" 

"VII" 

"VRR"<0> 

"VRR"<1> 

"VRR"<2> 

"D0_AND0PF" 

"Q_A0PF" 

"D0_AD0PF" 

"Q_AN0PF" 


<lnk>#2 ERROR(145): Pin name does not exist 
Drawing: "SCSYNCHLL" . SPICE .1.1 

No parameters 
Body: "BJT" (Path="7P"> 
Unfound pin: "Q_AND0PF" 

Drawing : " TBR_EUTERPE_PAS S 1 " . SPICE .1.1 

No parameters 
Body: "SCSYNCHLL" ( Path= " 156P" ) 

As far as I can tell my local copies of the schematic for this cell and the verilog models 
used to make the initial netlist are up to date. 

Tim 
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From: tbr 

Sent: Tuesday, October 1 1 , 1994 1 1 :47 PM 

To: 'Fred Obermeier' 

Cc: 'fwo@pelagon' 

Subject: 90p and m input. 

Follow Up Flag: Follow up 

Flag Status: Red 


Fred Obermeier wrote (on Tue Oct 1 O.- 
Tim, 

The 90p and m qualifiers can be found at: 
Range qualifier is not compatible with mpv 90: 
Found 1 different p- values: 90 
Found 1 different p- range values: m 
instance path : top . crrcvalurq_ 1 2 1 
cellname path: top.crrcvalurq_121 
leaf connections: 

instance path: top.xcr.x88p_l .x5p_l .xl21xl3p I.xl5p_l.rb2_ad90pl56v 
cellname path: top.cr .cr3a .cr3pgsas0.cr3pgsa .crgsa .saout_ad90pl56v 
instance path: top.xrgrgcrurcva!uhrru57.crrcvalurq_121 
cellname path: top.xbffdh2s .dO_admph 

Range qualifier is not compatible with mpv 90: 

Found 1 different p- values: 90 

Found 1 different p- range values: m 

instance path : top .crrcvalurq__n_ 1 2 1 

cellname path: top.crrcvalurq_n_121 
leaf connections: 

instance path: top.xcr.x88p_l.x5p_l .xl21xl3p_l,xl5p_l.rb2_and90pl56v 
cellname path: top.cr .cr3a .cr3pgsas0.cr3pgsa .crgsa .saout_and90pl 

56v 

instance path: top.xrgrgcrurcva!uhrru57.crrcvalurq_n_121 
cellname path: top.xbffdh2s .d0_andmph 

Csyn results from the old netlist can be _temporarily_ found in 
/u/two/tbr/faill/staypunVtbr_euterpe-pass 1 .csyn 

I hope the releasebom of tools/src/erc to completes sometime soon. 
It's been running for about an hour now. 

Thanks. I still have not been able to get a netlist. There is a 
problem with the body for the scsynchll cell which I'm waiting for 
someone to fix. I doubt the problem you give above will have changed 
though when I finally do get one, so it's almost certainly a real 
problem. 

Tim 


Exhibit C7 


Page 210 of 703 


Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphroditeJ 
Wednesday, October 12, 1994 12:19 AM 
'sysadmin@aphrodite' 

'hopper@aphrodite'; 'geert@aphrodite'; 'lisar@aphrodite' 
clock sync problem 


The clock sync problem is back: 

tbr@godzilla /n/staypuf t /sl/tbr/euterpe/verilog/bsrc/au/gards/ . parent 425 % rsh staypuft 
date; date Tue Oct 11 22:11:16 PDT 1994 Tue Oct 11 22:14:56 PDT 1994 tbr@godzilla 
/n/staypuf t/sl/tbr/euterpe/verilog/bsrc/au/gards/ .parent 426 % tbr@godzilla 
/n/staypuf t/sl/tbr/euterpe/verilog/bsrc/au/gards/ .parent 426 % rsh auspex date; date Tue 
Oct 11 22:16:30 PDT 1994 Tue Oct 11 22:15:25 PDT 1994 

The discrepancies of order 1 minute are causing "make" to malfunction again. 


Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, October 12, 1994 1:02 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/uu BOM 80.0 initiated by age completed @ Tue Oct 11 22:56:18 
PDT 1994 with exit status 1.. chip 
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From: Buffalo Chip [chip@rheaj 

Sent: Wednesday, October 12, 1994 3:17 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/iib BOM 72.0 initiated by age completed @ Wed Oct 12 01:11:47 
PDT 1994 with exit status 0 . . chip 
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From: Mark Hofmann [hopper@boreas] 
Sent: Wednesday, October 12, 1994 8:37 AM 
To: 'Tim B. Robinson' 
Subject: Re: clock sync problem 

Tim B. Robinson writes: 
The clock sync problem is back: 

tbr@godzilla /n/staypunVsl/tbr/euterpe/verilog/bsrc/au/gards/.parent 425 % rsh 
staypuft date;date 
Tue Oct 11 22:11:16 PDT 1994 
Tue Oct 1 1 22:14:56 PDT 1994 

tbr@godzilla /n/staypuft/sl/tbr/euterpe/verilog/bsrc/au/gards/.parent 426 % 
tbr@godzilla /n/staypuft/sl/tbr/euterpe/verilog/bsrc/au/gards/.parent 426 % rsh 
auspex date; date 
Tue Oct 1 1 22: 16:30 PDT 1994 
Tue Oct 11 22:15:25 PDT 1994 

The discrepancies of order 1 minute are causing 'make' to malfunction 
again. 

I wonder if this happened as a result of the cronus/oldcrounus switch. I noticed 
some amd funnies when the switchover was made. 

-hopper 
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From: John Campbell [solo@echidna] 

Sent: Wednesday, October 12, 1994 9:29 AM 

To: 'Tim B. Robinson' 

Cc: 'tom@aphrodite'; 'solo@aphrodite'; 'geert@aphrodite'; Vanthof@aphrodite'; 

'hopper@aphrodite' 
Subject: Re: cannot compile scsynchll 


as Tim B. Robinson was saying 


I am unable to get a top level LVS netlist compile becuase of a . .problem with the 
scsynchll cell. Here's what ged21vs is saying: 


<lnk>#l ERROR (14 5) : Pin name does not exist 
Drawing : » SCSYNCHLL" . SPICE .1.1 

No parameters 
Body: "BJT " (Path="6P") 
Unfound pin: 11 Q_AD 0 PF " 

Drawing : » TBR_EUTERPE_PASS 1 " . SPICE .1.1 

No parameters 
Body: "SCSYNCHLL " <Path= " 156P" ) 
Pins of the body: 

» PHI_A2P" 

" PHI__B2P" 

"VII" 

"VRR "<0> 

" VRR "<1> 

"VRR"<2> 

"D0_AND0PF" 

"Q_A0PF " 

"D0_AD0PF" 

"Q_AN0PF» 


<lnk>#2 ERROR (145) : Pin name does not exist 
Drawing: "SCSYNCHLL" . SPICE . 1 . 1 

No parameters 
Body: "BJT" (Path="7P" ) 
Unfound pin: "Q^ANDOPF" 

Drawing : "TBR_EUTERPE_PASS1 " . SPICE .1.1 

No parameters 
Body: " SCSYNCHLL" (Path= " 156P" ) 

.As far as I can tell my local copies of the schematic for this cell . .and the verilog 
models used to make the initial netlist are up to . .date. 


looks like your are out of date. here is the current status of what i think is released, 
you probably have version 1.1 of body. 1.1 


solo@echidna ~/proteus/ged 101 % more sc/scsynchll/BOM # Created by mkbom # $ld: B0M,v 3.0 
1994/10/07 10:05:44 LT solo Exp $ 

File 1.2 body. 1.1 

File 1.2 spice. 1.1 

File 1.2 spice_cn.l.l 
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soloOechidna ~/proteus/ged/sc/scsynchll 97 % cvs status cvs status: Examining 
File: BOM Status: Up-to-date 


Version: 
RCS Version: 
Sticky Tag: 
Sticky Date.- 
Sticky Options: 


3 . 0 
3 . 0 
(none) 
( none ) 
(none) 


Fri Oct 7 10:05:44 1994 

/p/cvsroot/proteus/ged/sc/scsynchll/BOM, v 


Status: Up-to-date 


File: body. 1.1 

Version: 
RCS Version: 
/p/cvsroot/proteus/ged/ sc/scsynchll/body . 1 . 1, v 


1.2 
1.2 


Fri OCt 7 10:00:54 1994 


Sticky Tag: 
Sticky Date : 
Sticky Options: 


(none) 
(none) 
(none) 


Status: Up-to-date 


File: spice. 1.1 

Version: 
RCS Version: 

/p/cvsroot/proteus/ged/sc/scsynchll/spice . 1 . 1 , v 


1.2 
1.2 


Fri Oct 7 10:00:57 1994 


Sticky Tag: 
Sticky Date: 
Sticky Options: 


(none) 
(none) 
(none) 


Status: Up-to-date 


1.2 
1.2 


Fri Oct 7 10:01:00 1994 


File: spice_cn.l.l 

Version: 
RCS Version: 

/p/cvsroot/proteus/ged/sc/scsynchll/spice_cn. 1 . 1, v 

Sticky Tag: (none) 

Sticky Date: (none) 

Sticky Options: (none) 


regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 73 4-8100 fax 408 7 34-813 6 
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From: tbr 

Sent: Wednesday, October 12, 1994 11:11 AM 

To: 'John Campbell' 

Cc: 'geert@aphrodite'; 'hopper@aphrodite'; 'solo@aphrodite'; 'tom@aphrodlte'; 

Vanthof@aphrodite' 

Subject: Re: cannot compile scsynchll 

Follow Up Flag: Follow up 

Flag Status: Red 


John Campbell wrote (on Wed Oct 12): 
as Tim B. Robinson was saying 


..I am unable to get a top level LVS netlist compile becuase of a 
..problem with the scsynchll cell. Here's what ged2lvs is saying: 


<lnk>#l ERROR(145): Pin name does not exist 
Drawing: "SCSYNCHLL". SPICE. 1.1 

No parameters 
Body: "BJT" (Path="6P") 
Unfound pin: "Q_AD0PF" 

Drawing: "TBREUTERPEPASS 1 ".SPICE. 1 . 1 

No parameters 
Body: "SCSYNCHLL" (Path="156P") 
Pins of the body: 

"PHI_A2P" 

"PHI_B2P" 

»VII" 

"VRR"<0> 

"VRR"<1> 

"VRR"<2> 

"DOANDOPF" 

"Q_A0VF" 

"D0„AD0PF" 

"Q_AN0PF" 


.. <lnk>#2 ERROR(145): Pin name does not exist 
Drawing: "SCSYNCHLL ".SPICE. 1 . 1 

No parameters 
Body: "BJT" (Path="7P") 
Unfound pin: "Q ANDOPF" 

Drawing: "TBR_EUTERPE_PASS1". SPICE. 1.1 

No parameters 
Body: "SCSYNCHLL" (Path="156P") 

..As far as I can tell my local copies of the schematic for this cell 
..and the verilog models used to make the initial netlist are up to 
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..date. 


..Tim 
Tim. 

looks like your are out of date, here is the current status of what i 
think is released, you probably have version 1 . 1 of body. 1 . 1 


OK, we found it. The problem was my fault. I had somehow forgotten 
to run the make in my proteus/ged/sc after picking up the change so 
although both the body and the connectivity file were OK, the edif 
file being used by emerge to patch up the bias lines had the wrong 
pins still. I have anew run going now. More news in 6 hrs! 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 12, 1994 11:11 AM 
'John Campbell' 

'geert@aphrodite'; 'hopper@aphrodite'; 'solo@aphrodite'; 'torn ©aphrodite'; 

Vanthof@aphrodite' 

Re: cannot compile scsynchll 


John Campbell wrote (on Wed Oct 12} : 
as Tim B. Robinson was saying . . . 


I am unable to get a top level LVS netlist compile becuase of a 
problem with the scsynchll cell. Here's what ged2lvs is saying: 


<lnk>#l ERROR(145): Pin name does not exist 
Drawing : ■ SCSYNCHLL " . SPICE .1.1 
No parameters 


Body: "BJT " (Path="6P") 
Unfound pin: "Q_AD0PF M 

Drawing : "TBR_EUTERPE_PASS1 " . SPICE .1.1 

No parameters 
Body: " SCSYNCHLL" (Path=" 156P" ) 
Pins of the body: 

11 PHI_A2P" 

" PHI_B2P" 

"VII" 

"VRR"<0> 

•»VRR"<1> 

"VRR"<2> 

"DO_ANDOPF" 

"Q_A0PF" 

"D0_AD0PF" 

»Q_AN0PF" 


<lnk>#2 ERROR (14 5) : Pin name does not exist 
Drawing: "SCSYNCHLL" . SPICE .1.1 
No parameters 


Body: "BJT" (Path= " 7P" ) 
Unfound pin: "Q^ANDOPF" 

Drawing : 11 TBR_EUTERPE_PASS1 " . SPICE . 1 . 1 

No parameters 
Body: "SCSYNCHLL" < Path=" 156P" ) 


As far as I can tell my local copies of the schematic for this cell 
and the verilog models used to make the initial netlist are up to 
date . 


looks like your are out of date. here is the current status of what i 
think is released. you probably have version 1.1 of body. 1.1 


OK, we found it. The problem was my fault. I had somehow forgotten to run the make in my 
proteus/ged/sc after picking up the change so although both the body and the connectivity 


Tim 


Tim. 
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file were OK, the edif file being used by emerge to patch up the bias lines had the wrong 
pins still. I have a new run going now. More news in 6 hrs ! 

Tim 
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From: Bob Morgan [bobm@mercury] 

Sent: Wednesday, October 1 2, 1 994 1 1 : 1 3 AM 

To: Vo@mercury' 

Cc: 'tbr@mercury' 

Subject: Euterpe pin diagram 

Tom, 

Hi. Do we have any kind of pin diagram, 
listing the pins and their numbers, anywhere? 
Also, is there anything that gives a brief 
description of what each pin does? 
Thanks, 
Bob 
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From: Ken Hsieh [ken@rimulac] 

Sent: Wednesday, October 12, 1994 12:28 PM 

To: 'tbr@aphrodite' 

Cc: 'hopper@rimulac'; 'geert@rimulac'; 'lisar@rimulac'; 'sysadm@rimulac' 
Subject: Re: clock sync problem 

Tim, 

I had manually sync the clock on all suns. 
We will keep eyes on it. 

Ken 

> From tbr@aphrodite Tue Oct 1 1 22:18:08 1994 

> Date: Tue, 1 1 Oct 1994 22: 1 8:38 -0700 

> From: tbr@aphrodite (Tim B. Robinson) 

> To: sysadmin@aphrodite 

> cc: hopper@aphrodite, geert@aphrodite, lisar@aphrodite 

> Subject: clock sync problem 

> Content-Length: 508 

> 
> 

> The clock sync problem is back: 

> 

> tbr@godzilla /n/staypuft/sl/tbr/euterpe/verilog/bsrc/au/gards/. parent 425 % rsh 

> staypuft date;date 

> Tue Oct 1 1 22:1 1:16 PDT 1994 

> Tue Oct 1 1 22: 14:56 PDT 1994 

> tbr@godzilla /n/staypuft/sl/tbr/euterpe/verilog/bsrc/au/gards/. parent 426 % 

> tbr@godzilla /n/staypuft/sl/tbr/euterpe/verilog/bsrc/au/gards/. parent 426 % rsh 

> auspex date;date 

>Tue Oct 11 22:16:30 PDT 1994 

> Tue Oct 1 1 22:15:25 PDT 1994 
> 

> The discrepancies of order 1 minute are causing 'make' to malfunction 

> again. 

> 

>Tim 

> 
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From: 
Sent: 
To: 

Subject: 


Geert Rosseel [geert@ambiorix] 
Wednesday, October 12, 1994 12:28 PM 
'hardheads@ambiorix' 
Machine usage 


Hi, 


As we get close to finishing Euterpe, a lot of people need to run large jobs. In order 
to get optimal usage of our machines, we've assigned machines to people. The assignment is 
posted on a white board neear the cafe. If you need more CPU power (or less), please let 
us know . 

The name CHIPQ stands for machines that should be used to release BOM's in /u/chip. The 
"short verilog" machines are the default machines for everybody who needs to run small 
verilog jobs. 


Geert 
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Subject: 


From: 
Sent: 
To: 


Cc: 


Graham Y. Mostyn [graham@thalia] 
Wednesday, October 12, 1994 3:07 PM 

'abbott@polyhymnia'; 'hopper@polyhymnia'; 'tbr@polyhymnia'; 'lisarfgpolyhymnia'; 
'geert@polyhymnia'; 'ras@polyhymnia'; 'graham@polyhymnia' 
'brianl@polyhymnia'; 'brian^polyhymnia'; 'jeffm@polyhymnia'; 'bfox@polyhymnia r ; 
'dane@polyhymnia'; 'hessam@polyhymnia'; 'rich@polyhymnia'; 7ves@polyhymnia'; 
'arya@polyhymn ia' ; , fwo@polyhym n ia' 
Reminder/2pm verif. mtg. 


> From graham@polyhymnia Fri Oct 7 15:06:29 1994 

> Date: Fri, 7 Oct 1994 15:08:14 -0700 

> From: graham@polyhymnia (Graham Y . Mostyn) 

> To: abbott@polyhymri.ia, hopper@polyhymnia, tbr@polyhymnia, 
lisar@polyhymnia, 

> geert ©polyhymnia, ras@polyhymnia 

> Subject: Verification 

> Cc : brianl@polyhymnia/ brian@polyhymnia , j ef fm@polyhymnia, 
b f ox@p o ly hymn i a , 

> dane@polyhymnia, hessam@polyhymnia , graham@polyhymnia, 
r ich@polyhymnia , 

> yves@polyhymnia, arya@polyhymnia , f wo@polyhymnia 

> Content -Length: 783 


> I would like to call a status review and scheduling meeting at 2pm 

> next Wednesday, October 12, concerning system verification using 

> Ptolemy. There are some verification tools needed to close holes that 

> exist. Let's meet in the War Room. 

> 

> AGENDA 

> - Assess scope of task and estimate of completion on the following: 

> 1. How shall we run Ptolemy on our database? Capability for Ptolemy 

> to accept database information one level above transistors , 

> 2. Current and voltage support (load/source information) within Ptolemy. 

> 3. Unix sockets to run Ptolemy, verilog and euterpe simulation in 

> parallel. 

> 4. Library development: - C++ training and support 

> - bringing and validating new models from 

> UC Berkeley 

> - model verification (analog celltest) 5. Other issues? 

> Thanks - Graham. 


> 


> 
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To: 


Sent: 


From: 


Curtis Abbott [abbott@tallis] 
Wednesday, October 12, 1994 8:03 PM 
'tbr@tallis'; 'craigC^tallis' 


Cc: 'dickson@tallis' 
Subject: ggfmu!8 

Richard and I talked this morning about the problem alluded to in 
my response to Brendan's message, included below. Richard tells me 
that ggfinul8 goes from 1 to 2 ticks per bit (i.e. from 2 to 3 gate 
levels) when the muxes are included to also do ggfmu!64. My response 
to that is let's drop ggfmul64 from this implementation. I need 
ggfmul8 to be as fast as possible, but the performance of ggfmul64 is 
not at all critical, since we can do CRC32 (the only real use I know 
of for ggftnul64 right now) pretty fast with table lookups in 8 bit 
whacks. Plus we're not doing nearly as many of them as ggfmul8's. 

- Curtis 


My mail of this morning to tbr, dickson, brendan, gmo; 

Brendan Eich wrote (on Tue Oct 1 1): 

Talked to dickson and he said ggfmul8 was likely to be microcoded using 
only a few bits of shift-xor per minor cycle. He estimated 40 ticks of 
latency and total hogging of the unit itself (which is fine) and of the 
issuing cylinder's pipe access (not so fine). So the simulator should be 
revised from its current wildly optimistic 4-cycle latency, 2 extra issue 
slots, to 8 and 7 respectively. 

This adds roughly 50% to the cost of the Reed- Solomon syndrome computation, 
which is in third place at 8.74% of cylinder 3 currently: 

% cumulative self self total 

time cycles cycles calls cy/call cy/call name 

61.35 5526624 5526624 5757 960 960 cable_in_handler 

13.05 6702053 1 175429 mpeg2_in_handler 

8.74 7489372 787319 320 2460 2460 rs_compute_syndrome 

4.53 7897877 408505 check_events 

2.88 8157083 259206 do_events 

I have a problem with this. I thought we were going to build 8 of the 
byte-wide units which would take 8 minor ticks, for a total of 16 per 
ggfmuI8 plus overhead. What's changed? 


Curtis 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Wednesday, October 12, 1994 9:19 PM 

To: 'djc@nosferatu'; 'jeffm@nosferatu'; 'billz@nosferatu' 

Cc: 'tbr@nosferatu' 

Subject: align tests 


I ran the align tests on BOM 142 and they seem to be running okay. The 
time specified to run the tests in the template was a dummy just to 
see if they would run. 

I ran the tests on terp to find out how long they would take on the 
accelerator. 


Design Name: ../tools/vendor/soft/stb/bin/terp 
Run Date: 121094 
Run ID: 13656 


Simulator: ../tools/vendor/soft/stb/bin/terp was built on Wed Oct 12 2:08:47 1994 

Run started on host: nosferatu at: Wed Oct 12 19:07:09 PDT 1994 

align_at_l Ran ok ... Equivalent Zycad simualtion time 40338600 
align_ld_l Ran ok ... Equivalent Zycad simualtion time 89637000 
align_st_l Ran ok ... Equivalent Zycad simualtion time 76 1 29800 
Total number equivalent Zycad simulation time = 206105400 (204395400) simticks 
Total number equivalent Zycad simulation time = 103052 sees, 1717 mins, 28 hrs (1703 mins, 28 hrs) 


Lisa R. 
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Subject: 


To: 


Cc: 


From: 


Sent: 


tbr 

Wednesday, October 12, 1994 9:39 PM 
'Bob Morgan' 
'vo@mercury , 
Euterpe pin diagram 


Follow Up Flag: Follow up 
Flag Status: Red 

Bob Morgan wrote (on Wed Oct 12): 
Tom, 

Hi. Do we have any kind of pin diagram, 
listing the pins and their numbers, anywhere? 
Also, is there anything that gives a brief 
description of what each pin does? 
Thanks, 
Bob 

Yes. Look in /u/chip/euterpe/baseplate/tablist.lst 

This is actually derived from the file padlist.lst which has comments. 

The two differ only in the assignment of power pins. 

This difference comes about because the functions of pins change 

from the chip to the tab frame through the space transformer. 

A user of the device would be interested in the tablist interface. 


Tim 
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From: 
Sent: 


tbr 


Wednesday, October 12, 1994 10:00 PM 


To: 


Subject: 


Cc: 


'Wayne Freitas' 
'pmayer'; 'woody' 
Cerberus Clock 


Follow Up Flag: Follow up 
Flag Status: Red 

Wayne Freitas wrote (on Wed Oct 12): 


Tim you indicated in your earier mail that the Cerberus Bus Interface 
tool (CBI) can control the Cerberus clock by cutting a trace. I'm 
assuming that this trace is on the main pcb, and if so can we make it 
where the trace has two vias spaced .1" apart using a .035" holes so 
we can just cut the trace and slap a small berg jumper on. 

It is on the main board. We should be able to provide the vias, but 
it may be necessary to include a fake component int he netlist. 

Jay, can you look at this please. We need to break it at the cerberus 
clock reference out at euterpe. 


Tim 


Exhibit C7 


Page 228 of 703 


From: Kurt Warn pier [wampler@thoas] 

Sent: Wednesday, October 12,1 994 1 1 :55 PM 

To: 'tbr@aphrodite'; 'tom@clio' 

Cc: 'agc@clio'; 'cadettes@clio'; 'geert@clio'; 'solo@clio'; Vo@clio' 

Subject: Re: xborff9df24s, etc 


Tom wrote : 


> Brianl forwarded your xborff9df24s error to me . . . It turns out that 
this 

> cell was successfully built once (on Aug 18) but for some reason 
didn ■ t 

> build in my recent retry. Unfortunately, some lobe was changed in the 

> meantime, so there is now an internal short between the Q_AD0PF target 

> and the Q_AND0PF target. Gdfpdl responds to this by throwing out 

> one 
of 

> the pins. Consistent with gards tradition, it prints an error message 

> and then returns a successful exit status (gdsgdf returned a non-zero 

> exit status, which was also wrong) . 

[snip] 

> So, what I plan to do is: 
[snip] 

> Try to figure out a way for piddles to detect gdfpdl errors so it 

> can return a useful exit status. 
> 

> Any objections or other comments from anyone? 
Tim queries: 


>Should we file a another tar on the exit code problem? 
Wampler replies: 


This was our TAR # 364, submitted originally on 09/28/92 (!) In our last go-round with 
SVR, I reviewed this along with the rest of the tar list, and responded to John Kulusich 
thusly : 

3 64 CLOSED GARDS 7.1 GEARS 7 . IX MINOR ENH 

"GARDS modules return success code even when they fail" 

I tested this under 7,115, and found that we still get exit code 0 from 
tools like G PLACE when they exit with fatal errors. We don't consider 
this one completely fixed yet. 

So... we haven't accepted it yet, but it is likely to get low priority from them, because 
it implicates many programs, and because error fatality is not clearly defined in all 
cases. We could hammer on them some more about this, but I'd rather not distract them 
from working on the protectpins fix, since we're trying to elevate that (and the GAROUT 
looping bug) to the highest priority right now, and I believe that it can have a 
significant impact on the top-level Euterpe route. 

- Kurt 
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From: tbr 

Sent: Thursday, October 13, 1994 12:32 AM 

To: 'Fred Obermeier' 

Cc: , dickson@pelagon'; 'fwo@pelagon'; 'hopper@pelagon'; 'tvo@pelagon' 

Subject: Rerun of csyn MPVCheck on calliope snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 


Fred Obermeier wrote (on Wed Oct 12): 
Hi, 

As a result of the recent MPVCheck fix, there was concern that problems 

may have been overlooked on calliope. However, a rerun of the fixed MPVCheck 

on the calliope snapshot (small_calliope-iter.sp) did not reveal any new 

real csyn problems. Whew. 

Why is it called smalI_caIliope-iter.sp. Are we sure this is the 
netlist that includes everything? 

The netlist still has all of those vref_0ph/vref64_0ph naming problems 
as before. Also, the interface pin, bgvrslvl.vref (cellname.pin), is 
now flagged probably due to a change in the rules file that mistakenly 
mapped all random vref* signals to Oph. This is no longer the case 
- vref signals must have explicit p qualifiers. 

Looks like good news. However, we have some significant problems on 
euterpe. With the new version the output has gon up from 40K to near 
800K. 

Tim 
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Sent: 
To: 

Cc: 


Subject: 


From: 


Kurt Wampler [wampler@thoas] 
Thursday, October 13, 1994 12:35 AM 
'dickson@demeter'; 'tbr@aphrodite' 
'brianl@aphrodite'; 'geert@demeter' 
Re: es route 


Richard Dickson wrote (on Sat Oct 8) : 

> es has been thru 4 iterations and i was poking around in stats 

> file to see what was happening and i was surprised by this. 

> 

> look at the metal 2 lengths, it wont converge if next time a 

> different 

> net gets a long unexpected metal 2 length. 
Tim replied: 


>One of 2 things happened. Either there really is something wrong with 
>the short net selections and it's makeing random choices, or more 
>likely it's putting in a significant number of tracks with the maze 
>router. I think brian's investigating this stuff, so you should point 
>him at the files. 

Wampler replies: 


Rich, I believe some of this behavior is attributable to a problem Brian and I noticed 
(and fixed) in euterpe/verilog/bsrc/subblk. rcf yesterday. 

The searchdepth=4 0 pass of the Metal2/3 route had inadvertently been deleted from the 
template routing strategy file. Looking at the /u/chip version of the es route, I observe 
that it hasn't been rerouted since Brian repaired the template routing strategy file. I 
hope that putting the file back in order will clear up some of the funny business we've 
been seeing with variation in metal2 lengths. If it's not to costly, you might want to 
trigger another route- from- scratch of es and see if the problem goes away. 


Kurt 
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From: tbr 

Sent: Thursday, October 13, 1994 12:36 AM 

To: 'lisar' 

Subject: forwarded message from Mark Semmelmeyer 

Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["1283" "Wed" "12" "October" "1994" "17:13:21" "-0700" "Mark Semmelmeyer" "mws@clytemnestra " nil "64" "Re: 
cj" MA From:" nil nil "10"]) 
Return-Path: <mws@clytemnestra> 

Received: from demeter.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA10490; Wed, 12 Oct 94 17:13:25 PDT 
Received: from clytemnestra.microunity.com by demeter.microunity.com (8.6.4/muse-sw.2) 

idRAA08816; Wed, 12 Oct 1994 17:13:22 -0700 
Received: from localhost by clytemnestra.microunity.com (8.6.4/muse-sw.2) 

id RAA 17250; Wed, 12 Oct 1994 17:13:21 -0700 
Message-Id: <1 994 10130013.RAA1 7250@clytemnestra.microunity.com> 
From: mws@clytemnestra (Mark Semmelmeyer) 

To: agc@demeter, geert@demeter, mws@demeter, tbr@demeter, dickson @demeter, 

woody@clytemnestra 
Cc: lisar@clytemnestra, gmo@clytemnestra 
Subject: Re: cj 

Date: Wed, 12 Oct 1994 17:13:21 -0700 


> From dickson@demeter Wed Oct 12 17:01:27 1994 

> 

> you'all, 

> 

> i believe we want byte interleaved like the data path for the 

> ibuf. the snake bus reads octlets so it has to 2: 1 mux the read data bus high half 

> low half, to keep the wires to this mux to reasonable lengths 

> the byte interleave like register file seem to be a good compromise. 

> 

> i can sramble the bits in euterpe.V 

> 

> i think that this will have an impact on the iq layout as well, mws ??? 
yes it would 

> i know that cj.pim is half right half wrong at this point, 
this is not my doing (you can say it is my non-doing) 

> 

> i'll redo the pirn file is age hasn't already ??? (cj) 

> 

> dickson 

> 

I guess it didn't happen, but I thought woody already 
scrambled the bits. Because IQ is different, it 
probably doesn't want the byte interleave of the datapath. 
Woody and I last thought that a quadlet interleave was 
best. We did not consider the snake bus, but I don't 
think we should optimize for it anyway (we can add 
buffers there?). The order was 
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0 

32 
1 

33 
2 

34 
3 

35 
64 
96 
65 
97 
66 
98 
67 
99 
4 

36 
5 

37 
6 

38 
7 

39 
68 
100 
69 
101 
70 
102 
71 
103 


If we change the order, we have to coordinate with lisar, 
gmo to change instruction loading / image file conventions. 
End 0 f forwarded message 
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From: 


tbr 


Sent: 
To: 

Subject: 


Thursday, October 13, 1994 12:55 AM 

'woody' 

floating inputs 


Follow Up Flag: Follow up 
Flag Status: Red 


We seem to have a bunch of floating inputs to cc (BOM 142) shown up by 
csyn. Are you expecting these? 


error (FloatinglnputCheck. 1 068) in file "tbr_euterpe-passl .spivs": input node has no driver and is not a top-level interface 
pin 

input 

instance path: top.xccu3 luu.ccdstrb 

cellname path: top.xbffdf4s.d0_admph 
topmost net 

instance path: top.cc_dstrb 

cellname path: top.cc_dstrb 
input 

instance path : top. xccu3 1 uO .cc dstrb n 
cellname path: top.xbffdf4s.d0 andmph 
topmost net 

instance path: top.cc dstrb_n 
cellname path: top.cc_dstrb_n 


instance path: top.xccu21u0 .cc_wuadd_n_3 1 
cellname path: top.xborl Idf2s.d]0_a0pf 
topmost net 

instance path : top . cc_wuadd_n_3 1 
cellname path: top.cc_wuadd_n_31 
input 

instance path: top.xccu21u0 ,cc_wuadd_n_2 1 
cellname path : top .xbor 1 1 df2 s. dOaOpf 

topmost net 

instance path: top.cc_wuadd_n_2 1 
cellname path: top.cc_wuadd_n_21 

input 

instance path: top.xccu21u0 .cc_wuadd_n_22 
cellname path: top.xborl Idf2s.d]_a0pf 

topmost net 

instance path: top.ccjwuadd n_22 
cellname path: top.cc wuadd_n_22 

input 

instance path: top.xccu21u0 .cc_wuadd_n_23 
cellname path: top.xborl Idf2s.d2_a0pf 
topmost net 

instance path: top.ccjwuadd _n 23 
cellname path: top.cc_wuadd_n_23 


input 
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input 

instance path: top.xccu21u0 .cc_wuadd_n_24 
ce I In ame path : top .xbor 1 1 df2 s. d3_a0pf 

topmost net 

instance path: top.cc_wuadd_n_24 
cellname path: top.cc_wuadd_n_24 

input 

instance path: top.xccu21u0 .cc_wuadd_n_25 
cellname path: top.xborl Idr2s.d4_a0pf 

topmost net 

instance path: top.cc_wuadd_n_25 
cellname path: top.cc_wuadd_n_25 

input 

instance path: top.xccu21u0 ,cc_wuadd_n_26 
cellname path: top.xborl Idf2s.d5_a0pf 

topmost net 

instance path: top.cc_wuadd_n_26 
cellname path: top.cc_wuadd_n_26 

input 

instance path: top.xccu21u0 .cc_wuadd_n_27 
cellname path: top.xborl Idi2s.d6_a0pf 

topmost net 

instance path: top.cc_wuadd_n_27 
cellname path: top.cc_wuadd_n_27 

input 

instance path: top.xccu21u0 .cc_wuadd_n_28 
cellname path: top.xborl Idf2s.d7_a0pf 

topmost net 

instance path: top.cc_wuadd_n_28 
cellname path: top.cc_wuadd_n_28 

input 

instance path: top.xccu21u0 .cc_wuadd_n JZ9 
cellname path: top.xborl Idf2s.d8 aOpf 

topmost net 

instance path: top.cc_wuadd_n_29 
cellname path: top.cc_wuadd_n_29 

input 

instance path: top.xccu21u0 .cc_wuadd_n_30 
cellname path: top.xborl Idf2s.d9_a0pf 
topmost net 

instance path: top.cc_wuadd_n_30 
cellname path: top.cc_wuadd_n_30 

input 

instance path: top.xccu20u0 ,cc_wuadd_n_42 
cellname path: top.xborl 6df2s.dl0_a0pf 

topmost net 

instance path: top.cc_wuadd_n_42 
cellname path: top.cc_wuadd_n_42 

input 

instance path: top.xccu20u0 .cc_wuadd_n_43 
cellname path: top.xborl 6df2s.dl l_aOpf 

topmost net 

instance path: top.cc_wuadd_n_43 
cellname path: top.cc_wuadd_n_43 

input 

instance path: top.xccu20u0 .cc_wuadd_n_44 
cellname path: top.xborl 6df2s.dl2_a0pf 
topmost net 

instance path: top.cc_wuadd_n_44 
cellname path: top.cc_wuadd_n_44 
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input 

instance path: top.xccu20u0 xc_wuadd_n_45 
cellname path: top.xborl6df2s.dl3_a0pf 

topmost net 

instance path: topxc_wuadd_n_45 
cellname path: top.cc_wuadd_n_45 

input 

instance path: top.xccu20u0 .cc_wuadd_n_46 
cellname path: top.xborl6df2s.dl4_a0pf 

topmost net 

instance path: top.cc_wuadd_n_46 
cellname path: top.cc_wuadd_n_46 

input 

instance path: top.xccu20u0 .cc_wuadd_n_47 
cellname path: top.xborl6df2s.dl5_a0pf 

topmost net 

instance path: topxc_wuadd_n_47 
cellname path: topxc_wuadd_n_47 

input 

instance path: top.xccu20u0 xc_wuadd_n_32 
cellname path: top.xborl6df2s.d0_a0pf 

topmost net 

instance path: topxc_wuadd_n_32 
cellname path: topxc_wuadd_n_32 

input 

instance path: top.xccu20u0 xc_wuadd_n_33 
cellname path: top.xborl6df2s.dl_a0pf 

topmost net 

instance path: top.cc_wuadd_n_33 
cellname path: topxc_wuadd_n_33 

input 

instance path: top.xccu20u0 xc_wuadd_n 34 
cellname path: top.xborl6df2s.d2_a0pf 

topmost net 

instance path: topxc_wuadd„n_34 
cellname path: topxc_wuadd_n_34 

input 

instance path: top.xccu20u0 ,cc_wuadd_n_35 
cellname path: top.xborl6df2s.d3_a0pf 

topmost net 

in stance path : top. cc_wuadd_n_3 5 
cellname path: topxc wuadd_n_35 

input 

instance path: top.xccu20u0 .cc_wuadd_n_36 
cellname path : top. xbor 1 6df2s . d4_a0pf 

topmost net 

instance path: top.cc_wuadd_n_36 
cellname path: topxc_wuadd_n_36 

input 

instance path: top.xccu20u0 xc_wuadd_n_37 
cellname path: top.xborl6df2s.d5_a0pf 

topmost net 

instance path: top.cc_wuadd_n_37 
cellname path: topxc_wuaddn_37 

input 

instance path: top.xccu20u0 xc wuadd n 38 
cellname path: top.xborl6df2s.d6_a0pf 

topmost net 

instance path : topxc_wuadd_n_3 8 
cellname path: topxc_wuadd_n_38 

input 
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instance path: top.xccu20u0 .cc_wuadd_n_39 
cellname path : top.xbor 1 6df2s.d7_a0pf 

topmost net 

instance path: top.cc wuadd n 39 
cellname path: top.cc_wuadd_nJ39 

input 

instance path: top.xccu20u0 xc_wuadd_n_40 
cellname path: top.xbor 16df2s.d8_a0pf 

topmost net 

instance path: top.cc_wuadd_n_40 
cellname path: top.cc_wuadd_n_40 

input 

instance path: top.xccu20u0 .cc_wuadd_n_41 
cellname path: top.xbor 16df2s.d9 _aOpf 
topmost net 

instance path: top.cc_wuadd_n_41 
cellname path: top.cc_wuadd_n_4 1 
** failed FloatinglnputCheck 
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From: 


tbr 


To: 


Sent: 


Subject: 


Thursday, October 13, 1994 12:56 AM 

'dickson' 

csyn problem 


Follow Up Flag: Follow up 
Flag Status: Red 


error (OutputShortsCheck.973) in file "tbr_euterpe-pass 1 .spivs": net has too many drivers 

topmost net: 

instance path: top.mc_u02_se_ena0 

cellname path: top.mc_u02_se_ena0 
drivers: 

instance path: top.xmcu02ul65u0.mc_u02_se_ena0 
cellname path: top.xborff2df8s .q_andOpf 
instance path: top.xmcu02ul87u0.mc_u02_se enaO 
cellname path: top.xborff2df8s .q_andOpf 

topmost net: 

instance path: top.mc_u02_se enaO n 

cellname path: top.mc_u02 se_enaO_n 
drivers: 

instance path: top.xmcu02ul65u0.mc_u02_se_ena0_n 
cellname path: top.xborff2df8s .q_adOpf 
instance path: top.xmcu02ul87u0.mc_u02_se_ena0_n 
cellname path: top.xborff2dfBs .q_adOpf 
** failed OutputShortsCheck 
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Cc: 

Subject: 


To: 


From: 


Sent: 


tbr 

Thursday, October 13, 1994 1:02 AM 

'geert'; 'bpw' 

'fwo' 


Interface trouble 


Follow Up Flag: Follow up 
Flag Status: Red 


Now csyn is fixed it looks like we have a problem with the register 
file. Looks like we still have a non-standard output . . . 


error (MPVCheck.528) in file "tbr_euterpe-passl. spivs": Node has conflicting MostPostive Voltage/Range qualifiers 

Range qualifier is not compatible with mpv 90: 

Found 1 different p- values: 90 

Found 1 different p- range values: m 

instance path: top.crrcvalurq_33 

cellname path: top.crrcvalurq_33 
leaf connections: 

instance path: top.xcr.x88p_l .x5p_l .x33xl3pj.xl5p_l.rb2_ad90pl56v 
cellname path: top.cr.cr3a .cr3pgsas0.cr3pgsa .crgsa .saout_ad90pl56v 
instance path: top.xrgrgcrurcvalulrru33.crrcvalurq_33 
cellname path: top.xbffdh2s .dOadmph 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Thursday, October 13, 1994 1:02 AM 
, geert@aphrodite'; 'bpw@aphrodite' 
'fwo@aphrodite' 
Interface trouble 


Now csyn is fixed it looks like we have a problem with the register file. Looks like we 
still have a non-standard output . . . 


error (MPVCheck. 52 8) in file "tbr_euterpe-passl . spivs" : Node has 

conflicting MostPostiveVoltage/Range qualifiers 

Range qualifier is not compatible with mpv 90 : 

Found 1 different p- values: 90 

Found 1 different p- range values: m 

instance path: top . crrcvalurq_3 3 

cellname path: top. crrcvalurq_3 3 
leaf connections: 

instance path: top . xcr .x8 8p_l .x5p_l 
.X3 3xl3p_l.xl5p_l.rb2_ad90pl5 6v 

cellname path: top.cr .cr3a . cr3pgsas0 . cr3pgsa .crgsa 
. saout_ad90pl56v 

instance path: top . xrgrgcrurcvalulrru3 3 . crrcvalurq_33 

cellname path: top.xbffdh2s .d0_admph 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Thursday, October 13, 1994 9:56 AM 

'Lisa Robinson' 

'tom@nosferatu'; 'sysadm@nosferatu'; Tim B. Robinson'; 'Geert Rosseel' 
Re: euterpe proteus build 


Lisa Robinson writes: 
Tom, 

I need some auspex disk space to build proteus for the euterpe tapeout . 

Hmmm... Let's see if we agree on all the relevant info: 

The initial purpose of this space is to run full rebuilds to make 
sure we're not using any orphaned unreproducable results -- this 
needs to be separate from /u/chip /proteus so we don't impact work in 
progress . 

When euterpe tapes out, we'll keep this around through chip testing 
and debug (at least a year?) --at this time it needs to be separate 
from /u/chip/proteus so that /u/chip/proteus can change. 

This will be a complete proteus (including celltest) , so it'll be 
the same size as the current one (93 3MB) . 

It should be on an auspex disk because we want fast access from 
every machine . 

If the above is correct, I think the sysadmins will be disappointed to learn that we want 
the major portion of a new disk. The only already- broached auspex disks with 1GB of 
space are s23 and s40. We know that s40 will grow fast as euterpe is completed, and for 
sure there won't be 1GB left when that's done. 

The issue with s23 is less clearcut . It's current tenant is /u/chip/calliope, which is 
stable at the moment. I've been assuming we'd start working on rev2 of calliope as soon 
as we see what kind of rocks we get from the first rev, which could start happening around 
the end of the year, give or take how things go in the fab. Mouss ' s comments of yesterday 
suggest that we may accept a calliope with some major parts non-f unctional , so a second 
rev could be a bit further off. 

I'm expanding the cc list on this to include tbr and geert, who may have some thoughts on 
this. 


Tom L 
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From: tbr 

Sent: Thursday, October 13, 1 994 1 0:46 AM 

To: Tom Laidig* 

Cc: 'Geert Rosseel'; 'Lisa Robinson'; , sysadm@nosferatu'; 'torrKgnosferatu' 

Subject: Re: euterpe proteus build 


Follow Up Flag: Follow up 
Flag Status: Red 


Tom Laidig wrote (on Thu Oct 13): 

Lisa Robinson writes: 
I 

|Tom, 
I 

1 1 need some auspex disk space to build proteus for the euterpe 
jtapeout. 

Hmmm... Let's see if we agree on all the relevant info: 

The initial purpose of this space is to run full rebuilds to make 
sure we're not using any orphaned unreproducable results - this 
needs to be separate from /u/chip/proteus so we don't impact work in 
progress. 

When euterpe tapes out, we'll keep this around through chip testing 
and debug (at least a year?) ~ at this time it needs to be separate 
from /u/chip/proteus so that /u/chip/proteus can change. 

This will be a complete proteus (including celltest), so it'll be 
the same size as the current one (933MB). 

It should be on an auspex disk because we want fast access from 
every machine. 

If the above is correct, I think the sysadmins will be disappointed to 
learn that we want the major portion of a new disk. The only already- 
broached auspex disks with 1GB of space are s23 and s40. We know that 
s40 will grow fast as euterpe is completed, and for sure there won't be 
1 GB left when that's done. 

I think the above is essentially correct. This version will serve the 
same function for euterpe that proteus-5.0 does for calliope. 

The issue with s23 is less clearcut. It's current tenant is 
/u/chip/calliope, which is stable at the moment. I've been assuming 
we'd start working on rev2 of calliope as soon as we see what kind of 
rocks we get from the first rev, which could start happening around 
the end of the year, give or take how things go in the fab. Mouss's 
comments of yesterday suggest that we may accept a calliope with some 
major parts non-functional, so a second rev could be a bit further off. 
I'm expanding the cc list on this to include tbr and geert, who may have 
some thoughts on this. 
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Much work has already been done on calliope rev2. Because we had good BOM 
control we have been checking into the regular repository. 

Tim 
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From: Buffalo Chip [chip@rheaj 

Sent: Thursday, October 13, 1994 11:19 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/lt BOM 62.0 initiated by age completed @ Thu Oct 13 09:18:12 
PDT 1994 with exit status 0 . . chip 
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From: john mudge [mudge@hera] 

Sent: Thursday, October 13, 1994 11:46 AM 

To: 'tbr@hera'; 'warren@hera'; 'jeff@hera' 

Cc: 'mudge@hera' 

Subject: Digital pins on the 83K 

Each, 

The tester was ordered with and has 160 digital pins. At one stage 
that was sufficient for euterpe. Now euterpe has grown to something 
like 194 (surprise surprise). New pin electronics boards can be 
plugged in at about $ 125k per group of 16. 

Let's meet at 1 1:00a.m. in PECR today to discuss our options on this, 
johnnymudge 
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From: Eric Murray [ericm@microunity.com] 

Sent: Thursday, October 1 3, 1 994 1 1 :50 AM 

To: Tim B. Robinson' 

Cc: 'tom@microunity.com'; 'geert@microunity.com'; 'lisar@microunity.com'; 

'sysadm@microunity.com'; 'tom@microunity.com' 
Subject: Re: euterpe proteus build 


Tim B. Robinson wrote: 


> Tom Laidig wrote (on Thu Oct 13) : 
> 

> The issue with s23 is less clearcut. It's current tenant is 

> /u/chip/calliope, which is stable at the moment. I've been assuming 

> we'd start working on rev2 of calliope as soon as we see what kind of 

> rocks we get from the first rev, which could start happening around 

> the end of the year, give or take how things go in the fab. Mouss's 

> comments of yesterday suggest that we may accept a calliope with some 

> major parts non- functional, so a second rev could be a bit further 
off. 

> I'm expanding the cc list on this to include tbr and geert, who may 
have 

> some thoughts on this. 

> 

> Much work has already been done on calliope rev2 . Because we had good 
BOM 

> control we have been checking into the regular repository. 

does this mean than /u/ chip/calliope (auspex : /s2 3 /chip -calliope) won't be growing very 
much? or if it does grow, it won't be all that fast? there's 113 7 megs free on it, if we 
put this new proteus there, there 'd be only 200 megs free. 

if we put the new proteus there and chip -calliope grows past 2 00 megs, can it have 
symlinks pointing to other disks with free space on them? that'd help a lot. 


ericm ericm@microunity.com 
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From: Wayne Freitas [wayne@echidna] 
Sent: Thursday, October 13, 1994 11:56 AM 
To: 'bpw@echidna'; 'tbr@echidna' 
Subject: finding V & I levels in Euterpe 

Hi, 

I'm interested in knowing what the output levels, sink/source, slew 
and anticipated skew for the Euterpe pins that read/write to the front 
panel display. 1 looked through some of the verilog files and 
euterpe.doc but was unable to find this information. Could you 
provide me this information, and also where to find it so I won't have 
to keep coming around to ask these simple questions all the time. 

Thanks, 

Wayne 
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From: Geert Rosseel [geert@rhea] 

Sent: Thursday, October 13, 1994 12:41 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert : 

pageme gmake geert_euterpegards start : Oct_13_10 : 21 end: Oct_13_10:39 exit 
1 
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From: Jay Tomlinson [woody@luckboy] 
Sent: Thursday, October 13, 1994 2:32 PM 
To: Tim B. Robinson' 
Cc: 'pmayer@aphrodite'; 'Wayne Freitas' 
Subject: Cerberus Clock 

Tim B. Robinson wrote (on Wed Oct 12): 
Wayne Freitas wrote (on Wed Oct 12): 


Tim you indicated in your earier mail that the Cerberus Bus Interface 
tool (CBI) can control the Cerberus clock by cutting a trace. I'm 
assuming that this trace is on the main pcb, and if so can we make it 
where the trace has two vias spaced . 1 " apart using a ,035" holes so 
we can just cut the trace and slap a small berg jumper on. 

It is on the main board. We should be able to provide the vias, but 
it may be necessary to include a fake component int he netlist. 

A fake component is not required according to pattie. 

Jay, can you look at this please. We need to break it at the cerberus 
clock reference out at euterpe. 

Tim 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Jeff Marr [jeffm@microunity.com] 

Thursday, October 13, 1994 4:21 PM 

'euterpe@gaea' 


in article <199410102232 . PAA1312 0@kephalos , microunity. com> , 
jeffm@kephalos.microunity.com {Jeff Marr) writes: 


> 


> 


1. Memory management has to be turned off in all three cases, but 
a clear or machine check currently leaves that bit untouched. 


> 


2 . It also may be a good idea to disable the Hermes channels at 


the 


> 


> 


beginning of a reset, clear, or machine check sequence. Are there 
cerberus bits that should be set/cleared? 


For ease of implementation, dickson has suggested that loading a byte, or bytes, worth of 
defaults on a clear and machine check is best. I propose that Cerberus Octlet 6 bits 55:0 
be set to defaults on a clear/mc. This would set the following to their default values: 

NB Priority 

Hermes Channel Disables 
Memory Management Enable 
I/DCache Configuration 
Channel Under Test 
CidleO/1 

I believe that the first three are essential, and the last three get pulled into the fray 
because they don't line up on byte boundaries, and it doesn't hurt to set them to their 
default values. 


> 4 . What is the exposure of possibly clobbering some dram contents 

> on a machine check? Is it possible to automatically set the 

> output set high bit in cerberus register 10 at the beginning of 

> a clear or machine check? 
> 

I am not sure that we can, in all cases, prevent dram corruption from a machine check. If 
the machine check comes in the middle of a write, part of the data may be junk. Setting 
the output set high put would not protect against this case. It does protect against 
spurious traffic resulting from 

the reset pulse sent to the dram controller and interface logic. Is it worth doing 
anything about this? 
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From: Eric Murray [ericm@microunity.com] 

Sent: Thursday, October 13, 1994 4:30 PM 

To: Tom Laidig' 

Cc: 'ericm@microunity.com 1 ; 'tbr@microunity.com'; *tom@m icrounity.com'; 

'geert@microunity.com'; ' lisar@microunity.com'; 'sysadm@microunity.com' 
Subject: Re: euterpe proteus build 


Tom Laidig wrote: 
> 

> Eric Murray writes : 

Tim B. Robinson wrote: 
> 
> 

> Tom Laidig wrote (on Thu Oct 13) : 
> 

> The issue with s23 is less clearcut. It's current tenant is 

> /u/chip/calliope, which is stable at the moment. I've been 
assuming 

> | > we ' d start working on rev2 of calliope as soon as we see what 

> j > kind 
of 

> j > rocks we get from the first rev, which could start happening 
around 

> |> the end of the year, give or take how things go in the fab. 
Mouss ' s 

> I > comments of yesterday suggest that we may accept a calliope with 
some 

> |> major parts non- functional , so a second rev could be a bit 

> j > further 
off - 

> \> I'm expanding the cc list on this to include tbr and geert, who 
may have 

> j> some thoughts on this. 

* h 

> | > Much work has already been done on calliope rev2 . Because we had 
good BOM 

> control we have been checking into the regular repository. 

does this mean than /u/chip/calliope (auspex: /s23/chip-calliope) 
won't be growing very much? or if it does grow, it won't be all that 
fast? there's 1137 megs free on it, if we put this new proteus 
there, there' d be only 200 megs free. 

if we put the new proteus there and chip- calliope grows past 2 00 
megs, can it have symlinks pointing to other disks with free space on 
them? that ' d help a lot . 

> 

> /u/chip/calliope will certainly grow lots. The work tbr mentioned 

> that has been done has so far only involved builds in various people's 

> home directories, not under /u/chip. This will change, and we'll for 

> sure overflow the one disk, just as euterpe has done. Although 

> symlinks can (and will) be used to manage this, it doesn't look to me 

> as if it would be easy to make that split between what's there now and 

> what will be added. I understand the desire to avoid wasting disk 

> space, but I think I can guarantee that the remainder of s23 won't be wasted. 
> 

> I strongly recommend that we carve up a virgin disk (if you'll pardon 

> the gruesome metaphor) . Can I just create the required directory on 

> s41? Lisar wants to start this going tonight. 

yea, go for it. 
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ericm ericmOmicrounity ♦ com 
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From: Tom Laidig [tom@clio] 

Sent: Thursday, October 1 3, 1 994 5:26 PM 

To: 'Eric Murray' 

Cc: 'tbr@microunity.com'; , tom@microunity.com , ; 'geert@microunity.com'; 'lisar@microunity.com'; 

'sysadm@microunity.com' 
Subject: Re: euterpe proteus build 


Eric Murray writes: 
Tim B . Robinson wrote : 


> Tom Laidig wrote (on Thu Oct 13) : 
> 

> The issue with s23 is less clearcut. It's current tenant is 

> /u/chip/calliope, which is stable at the moment. I've been assuming 

> we'd start working on rev2 of calliope as soon as we see what kind 
of 

|> rocks we get from the first rev, which could start happening around 
\> the end of the year, give or take how things go in the fab. Mouss ' s 
I > comments of yesterday suggest that we may accept a calliope with 
some 

|> major parts non- functional , so a second rev could be a bit further 
off . 

|> I'm expanding the cc list on this to include tbr and geert, who 
j > may 
have 

> some thoughts on this. 

> Much work has already been done on calliope rev2 . Because we had 

> good 
BOM 

> control we have been checking into the regular repository. 

does this mean than /u/chip/calliope (auspex: /s23/chip- calliope) won't 
be growing very much? or if it does grow, it won't be all that fast? 
there's 1137 megs free on it, if we put this new proteus there, there ' d 
be only 200 megs free. 

if we put the new proteus there and chip- calliope grows past 2 00 megs, 
can it have symlinks pointing to other disks with free space on them? 
that'd help a lot. 

/u/chip/calliope will certainly grow lots. The work tbr mentioned that has been done has 
so far only involved builds in various people's home directories, not under /u/chip. This 
will change, and we'll for sure overflow the one disk, just as euterpe has done. Although 
symlinks can (and will) be used to manage this, it doesn't look to me as if it would be 
easy to make that split between what's there now and what will be added. I understand the 
desire to avoid wasting disk space, but I think I can guarantee that the remainder of s23 
won't be wasted. 

I strongly recommend that we carve up a virgin disk (if you'll pardon the gruesome 
metaphor) . Can I just create the required directory on s41? Lisar wants to start this 
going tonight . 


Tom L 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Lisa Robinson [lisar@rhodanJ 
Thursday, October 13, 1994 5:45 PM 
'Eric Murray' 

'ericm@microunity.com'; 'geert@microunity.com'; 'sysadm@microunity.com'; 
'tbr@microunity.com'; 'tom@microunity.com'; Tom Laidig' 
Re: euterpe proteus build 


Eric Murray wrote (on Thu Oct 13) : 
Tom Laidig wrote: 

> Eric Murray writes : 
> 

> Tim B. Robinson wrote; 

> > 

> > Tom Laidig wrote (on Thu Oct 13) : 


> I strongly recommend that we carve up a virgin disk (if you'll pardon 

> the gruesome metaphor) . Can I just create the required directory on 

> S41? Lisar wants to start this going tonight. 

yea, go for it. 


> 


ericm 


ericmOmicrounity . com 


Thanks . 


Lisa R. 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday, October 13, 1994 5:50 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/iq BOM 37.0 initiated by age completed @ Thu Oct 13 15:49:00 
PDT 1994 with exit status 0 . . chip 
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From: Tom Laidig [tom@clio] 

Sent: Thursday, October 13, 1994 5:53 PM 

To: 'Lisa Robinson' 

Cc: 'ericrT^MicroUnity.com'; 'geert@MicroUnity.com'; 'sysadm@MicroUnity.com'; 
'tbr@MicroUnity.com'; 'tom@MicroUnity.com' 

Subject: Re: euterpe proteus build 

Lisa Robinson writes: 

|Eric Murray wrote (on Thu Oct 13): 

j Tom Laidig wrote: 

j > 

j > I strongly recommend that we carve up a virgin disk (if you'll pardon 

j > the gruesome metaphor). Can I just create the required directory on 

j >s41? Lisar wants to start this going tonight. 

| yea, go for it. 

| Thanks. 

1 drwxr-xr-x 2 lisar root 512 Oct 13 15:52 /s41/euterpe-proteus 
Tom L 
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From: Tom Karzes [karzes@MicroUnity.com] 

Sent: Thursday, October 13, 1994 7:24 PM 

To: 'gmo@MicroUnity.com' 

Cc: 'abbott@MicroUnity.com'; 'lisa@MjcroUnity.com' 

Subject: assembler/simulator bug status 


Ok, yesterday's tgcc 128-bit constant bug seemes to have been fixed last night, although I 
didn't realize it until today when I happened to use it and noticed it had changed (please 
send me mail next time; I could have rerun my tests last night if I'd been told). 


Here ' s the current status : 


rotate 
expand 
compress 
extract 
field 
copy swap 
shuf f lemux 
select 


failed 
passed 
passed 
failed, 
failed 
passed 
passed 
passed 


also missing opcodes for group 1 


I have 5 opcodes which fail: 


GUSHI1.12 8 


This is the "large immediate" version. It isn't 
setting the high bit of the shift amount. Should 
be trivial to fix. By the way, I didn't notice a 
problem with the other "large immediate" opcodes, 
so it looks like this is an isolated case. 


GUEXTRACT 
GEXTRACT 


These appear to be ignoring the high shift amount bit. 


GDEPI 
GWTHI 


In the failing example I looked at, the shift amount 
was zero and these instructions were acting like nops 
(i.e. they were failing to sign extend) . 

Look at -karzes/mysoft/stb/terp-src/stb/stand/diag/xlu. c for examples of each of these 
errors . 


In addition, the group 1 gextracts are still broken. 


Now that we've finally identified the simulator bugs (as opposed to the tgcc bugs), there 
aren't very many and they all look trivial to me. Let's get these fixed tonight and I'll 
rerun my tests. Thanks. 
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From: tbr 

Sent: Thursday, October 1 3, 1 994 1 1 :03 PM 

To: 'Eric Murray 1 

Cc: 'geert@MicroUnity.com'; 'lisar@MicroUnity.com'; 'sysadm@MicroUnity.com'; 

'tom@MicroUnity.com' 

Subject: Re: euterpe proteus build 

Follow Up Flag: Follow up 

Flag Status: Red 


Eric Murray wrote (on Thu Oct 13): 

Tim B. Robinson wrote: 

> 
> 

> Tom Laidig wrote (on Thu Oct 13): 

> 

> The issue with s23 is less clearcut. It's current tenant is 

> /u/chip/calliope, which is stable at the moment. I've been assuming 

> we'd start working on rev2 of calliope as soon as we see what kind of 

> rocks we get from the first rev, which could start happening around 

> the end of the year, give or take how things go in the fab. Mouss's 

> comments of yesterday suggest that we may accept a calliope with some 

> major parts non-functional, so a second rev could be a bit further off. 

> I'm expanding the cc list on this to include tbr and geert, who may have 

> some thoughts on this. 
> 

> Much work has already been done on calliope rev2. Because we had good BOM 

> control we have been checking into the regular repository. 

does this mean than /u/chip/calliope (auspex:/s23 /chip-calliope) 

won't be growing very much? or if it does grow, it won't 

be all that fast? there's 1137 megs free on it, if we put 

this new proteus there, there'd be only 200 megs free. 

if we put the new proteus there and chip-calliope grows past 

200 megs, can it have symlinks pointing to other disks with free 

space on them? that'd help a lot. 

The symlinks for the gards builds for euterpe have been effective in 
keeping the /u/chip propper size under control. I suggest we should 
do the same with calliope before rebuilding it, so then I would not 
expect it to grow a lot. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Thursday, October 1 3, 1 994 1 1 :03 PM 

To: 'Eric Murray' 

Cc: 'geert@microunity.com'; 'lisar@microunity.com'; 'sysadm@microunity.com'; 

'tom@microunity.com' 
Subject: Re: euterpe proteus build 


Eric Murray wrote (on Thu Oct 13) : 
Tim B. Robinson wrote: 


> Tom Laidig wrote (on Thu Oct 13) ; 
> 

> The issue with s23 is less clearcut. It's current tenant is 

> /u/chip/calliope, which is stable at the moment. I've been 
assuming 

> we'd start working on rev2 of calliope as soon as we see what kind 

of 

> rocks we get from the first rev, which could start happening 
around 

> the end of the year, give or take how things go in the fab. 
Mouss 1 s 

> comments of yesterday suggest that we may accept a calliope with 
some 

> major parts non-functional, so a second rev could be a bit further 
off. 

■> I'm expanding the cc list on this to include tbr and geert, who 
may have 

> some thoughts on this. 
> 

> Much work has already been done on calliope rev2 . Because we had good BOM 

> control we have been checking into the regular repository. 

does this mean than /u/chip/calliope (auspex: /s23/chip-calliope) 

won't be growing very much? or if it does grow, it won't 

be all that fast? there's 1137 megs free on it, if we put 

this new proteus there, there 'd be only 2 00 megs free. 

if we put the new proteus there and chip- calliope grows past 

200 megs, can it have symlinks pointing to other disks with free 

space on them? that ' d help a lot. 

The symlinks for the gards builds for euterpe have been effective in keeping the /u/chip 
propper size under control. I suggest we should do the same with calliope before 
rebuilding it, so then I would not expect it to grow a lot. 

Tim 
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From: tbr 

Sent: Thursday, October 1 3, 1 994 1 1 :31 PM 

To: 'Mark Hofmann' 

Cc: 'cadettes@tomato'; 'Fred Obermeier'; 'Geert Rosseel' 

Subject: Re: Memo Rev 2. 
Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Thu Oct 13): 

Fred Obermeier writes: 
Is the plan for mnemosyne revision 2 to use our current rules? 
Currently the "csyn -chip mnemosyne ..." invocation will use the 
old csyn rules, old parts of the csyn code, and old voltages. 
Someone should let me know when to update the rules and voltages, 
and turn off the old code. 

Fred, 

You've raised a good point. Probably son-of-Mnemo should not be called 
Mnemo, but ought to take the mantle of another name just to avoid such 
name clashes as these. 

Comments? Names? 

It will use the latest cell family and methodology as used for 
euterpe. I agree we need a new name to prevent confusion. 
It's all greek to me. How about mnemosyne2? 

Tim 
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Sent: 


To: 


From: 


Mark Hofmann [hopper@boreas] 
Friday, October 14, 1994 8:43 AM 
Tim B. Robinson' 


Subject: Re: clock sync 

Tim B. Robinson writes: 
There is still a clock sync problem: 

tbr@gamorra ~/euterpe/verilog/bsrc 474 % ! ! 

rsh auspex date ; date 

Thu Oct 13 23:52:10 PDT 1994 

Thu Oct 13 23:51:15 PDT 1994 

What is being done to address this? 

I had lunch with Gardner yesterday and asked him if he ever had to deal 
with these issues. He says that Brendan Eich ought to know this stuff cold. 
Brendan apparently wrote the NTP stuff for the SGFs (This code goes 
out and polls the National Bureau of Standards for the precise time. 
Gardner said he had all machines at Sgi (after they did this) to within 
hundredths of a second. At Mips they had some of the same problems we are 
seeing now.) 


-hopper 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Friday, October 14, 1994 10:08 AM 
To: Tim B. Robinson' 

Cc: 'sysadmin@MicroUnity.com'; 'hopper@MicroUnity.com' 
Subject: Re: clock sync 

Tim B. Robinson wrote: 

> 
> 

> There is still a clock sync problem: 

> 

> tbr@gamorra ~/euterpe/verilog/bsrc 474 % ! ! 

> rsh auspex date ; date 

> Thu Oct 13 23:52:10 PDT 1994 

> Thu Oct 13 23:51:15 PDT 1994 

> 
> 

> What is being done to address this? 
i'm working on it. 


ericm ericm@microunity.com 
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From: Lisa Robinson [lisar@godzilla] 

Sent: Friday, October 1 4, 1 994 1 1 :24 AM 

To: 'staffers@nosferatu'; 'jt@nosferatu'; 'hopper@nosferatu' 

Subject: Schedule meeting action items. 


Action items from the Wednesday schedule meeting. 
? ? ? Van Dyke needs NFS for Windows 3 . 5 

mudge To call a meeting regarding reliability testing and burn in of 
chips 

ramos To call a meeting regarding reliability testing and burn in of 
Hestia 

mouss Curtis need office space and to discuss organization 

curtis Should include shorter term milestones with dates on his slide 

h? Should the TV guide be scheduled with a view to demoing it on 
an SGI in November? 

Graham To check with Rich on the pll baseplate completion date 

craig Needs to confirm the euterpe cerberus read only register 

values. Also needs to provide a definition of the gf instructions. 

Al Again the concern was raised regarding the relative priorities 
of the reticle sets. Graham suggested that a meeting to review 
the metal rules next week could be the vehicle to then 
priorize the revisions of the reticle metal data. 

Al, hopper, geert, graham, tbr, mudge - is this appropriate and if so 
could one of you call the meeting. 

jt Distribute the ECO process to Lisar and Loretta. (Done) 


mudge/ Jt • s group needs the SRAM and other power dissipation numbers 

graham next week. 

Buck/ Need a PO for another compressor. 
Ann 

mouss Ann needs to discuss stepper focus? 


Last meeting's action item: 


tbr Needs to get with Craig this afternoon to finalize the event 
daemon architecture . STILL OPEN 

steve To provide mouss with the details of the PCB 

contract /placement agreement with a view to working with them 
re. hopper's position opening. DONE 

hopper Into final Euterpe verification so will require round the 

clock sysadm support. DOING 

mouss To pass graham a resume re. wireless position opening. ?? 

graham Channel 3/4 modulation is at least 10% o the available machine 


Exhibit C7 


Page 263 of 703 


cycles, is this the right way to go? Graham to call meeting. 

STILL 

OPEN? 

graham/ curt is ISDN product realization should be planned for. 

Curtis may need more headcount . Should plan for shipment of 
30,000 ISDN mediacomputers during the first 6 months of next 
year. DOING?? 

lisar Needs a technician to support wayne. lisar will go ahead with 
pursuing filling this position. 

DOING 

lisar Requires design groups to adhere to the board/box bringup plan 
jointly developed with the design groups. Plan calls for 
test result documentation and problem tracking where 
appropriate, lisar should be more avidly selling the approach, 
graham requested a meeting to go over the test plan details. 

DONE 

mudge lisar thinks johnny needs something (test vectors?) from her 

group for calliope test. Johnny and lisar should to get together. 

DONE 

Al I got the impression that the test wafer discussion was a 
non- issue 

but just to clarify. The castor/pollux and orchis masks will be 
processed in parallel in the fab. Castor/pollux will be used to debug 
the process and orchis will be used as a yield monitor once we have 
yielding castor/pollux transistors. Al to clarify. 

DONE 

lisar JT would like to have a streamlined process for 

producing /approving the documentation associated with 
fabrication of box parts. Lisar to look into automating this. 

DOING 

steve Should buy for the build of 50 units on 10/31. DOING 

Needs to look at improving NTSC performance. Addressed 

new hire 

Van Dyke Needs the Mayan license agreement First 

cut DONE 

Van Dyke Needs a stable NT machine. Someone (?) should get a 
configuration from Seattle. ???? 


curtis 
by 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@tomato] 

Friday, October 14, 1994 12:29 PM 

Tim B. Robinson'; 'Mark Semmelmeyer'; 'Geert Rosseel' 

Vant^tomato' 

checking clock phases 


There's been some concern that clock phases are correct on the Euterpe designs. The 
"gloss" tool can be used to check this. Before I make a wider announcement I was looking 
for some guinea pigs that might want to try things out. 

To check a design: 

1. topt -e <design> . edif -K <deisgn> . strength -o out.edif \ 

-g /u/ chip/pro teus/leaf gen/ topt List 

2. edif2gloss out.edif <design> 


3. gloss -clocks phi_a2p phi_b2p -phaseCheckOnly out >& <design>.log 
Check <design> . warn for phase violations. 
Please ask if you have questions. 

NB: This does _not_ check the "tau" signals. Dave is looking at adding that capability 
into Topt . 


-thanks, 
hopper 
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From: tbr 

Sent: Friday, October 14, 1994 1:06 PM 

To: 'bobm' 

Subject: forwarded message from Richard Dickson 

Follow Up Flag: Follow up 
Flag Status; Red 

Did the document get updated to track this on? 
Tim 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["215" "Mon" "10" "October" "1994" "21: 10:50" "-0700" "Richard Dickson" "dickson@gamorra " nil "9" 
"euterpe/verilog/bsrc/ce cerbtempreg.V" " A From:" nil nil "10"]) 
Return-Path: <dickson@gamorra> 

Received: from gamorra.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA22417; Mon, 10 Oct 94 21:07:56 PDT 
Received: from localhost by gamorra.microunity.com (8.6.4/muse-sw.2) 

id VAA22129; Mon, 10 Oct 1994 21:10:50 -0700 
Message-Id: < 1994101 10410.VAA22129@gamorra.microunity.com> 
From: dickson@gamorra (Richard Dickson) 

To: euterpe-checkins-dist@gamorra, lisar@gamorra, tbr@gamorra, tom@gamorra 
Subject: euterpe/verilog/bsrc/ce cerbtempreg.V 
Date: Mon, lOOct 1994 21:10:50-0700 

Update of /p/cvsroot/euterpe/verilog/bsrc/ce 

In directory gamorra:/N/rama/rootys5/dickson/euterpe/verilog/bsrc/ce 

Modified Files: 

cerbtempreg.V 
Log Message: 
power on defaults reg3 1 
<47:43>=00101 <39:35>=01010 

End of forwarded message 
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From: 
Sent: 
To: 


Cc: 

Subject: 


Bill Zuravleff [billz@melpomene] 
Friday, October 14, 1994 1:33 PM 

'euterpe@melpomene'; Tim B. Robinson'; 'Lisa Repka'; 'Guillermo A. Loyola'; 'Curtis Abbott'; 

'Scott Furman' 

, euterpe@melpomene' 

D cache miss penalty, reality check 


Y'all, 


Now that we've done (one) d-cache fill on the euterpe logic model, the miss penalty can 
be *measured* and not just estimated. 

The miss penalty, filling from DRAM, is 400 ticks = 80 major cycles = 80 issue slots. 

Pertinent system parameters : 

1) sofa clock freq. /DRAM clock freq = 13. 

This is based on 1 . 3GHZ/100MHz . Obviously, both of these frequencies may be wrong. 

2) NB (non-blocking load buffer) is empty at time of cache line request, 

3) Both DRAM banks are precharged. 

Where do all the cycles go? 

OK, to squeeze 64 bytes out of DRAM takes 16 DRAM clocks. 

There's an additional 3 DRAM clocks to ACTIVATE and (2 plus a fraction, call it) 3 of read 
latency. That's (16+3+3) *13 = 288 ticks of latency through DRAM. The rest is "overhead" 
and can be accounted for as follows (this is measured off of a simulation trace) . 

11 - from Miss to first NB request 

10 - through NB to Peripheral Broadcast Bus 

22 - through Peripheral Broadcast Bus, DRAM Controller, and sync to DRAM clock 28 0 - 
through DRAM 

6 - back through controller, arbitrate for Peripheral Return Bus 
3 6 - back through NB, back through datapath pipeline, tag update 
35 - original load is rescheduled (original load is continually rescheduled 
on a 50 tick cycle, eventually it hits) . 


Reasons the Miss Penalty may increase : 

1) Other non-blocking loads/store in NB queues; particularly 1/s to DRAM; particularly 
high priority requests to DRAM; In particular, since cache line requests are serviced at 
low priority and the normal operating mode of euterpe is with NB full -- some of which are 
high priority DRAM requests -- the cache line request is likely to be delayed 
significantly. It's possible for the cache line request to wait forever behind high 
priority requests to DRAM sent by other threads . 

2) Correct DRAM bank is ACTIVE on wrong page. 

3) There are numerous points where data has to "sync to a beat": 

a) pbb (1 of 4 beat) 

b) DRAM (1 of 13 beat) 

c) prb (1 of 4 beat for frame, 1 of 5 beat for frame within arbitration 
super- frame) 

d) returned NB load (1 of 20 beat) 
3) rescheduled Miss (1 of 5 0 beat) 

Sometime you're lucky, sometimes you're not. 

Reasons the Miss Penalty may decrease: 

1) Faster DRAM or lower sofa freq/dram clock freq ratio. 

2) Correct DRAM bank is ACTIVE on correct page. 


Hope this is somewhat in accord with simulator. 
Please holler if you think there's something wrong. 

We anticipate the I-cache miss penalty to be greater. 


400 
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From: Bob Morgan [bobm@ mercury] 
Sent: Friday, October 14, 1994 2:10 PM 
To: 'tbr@aphrodite' 

Subject: Re: forwarded message from Richard Dickson 


Yes, I updated them. 
Bob 

Begin Included Message 

>From tbr@aphrodite Fri Oct 14 1 1 :06:21 1994 
Date: Fri, 14 Oct 1994 11:06:20 -0700 
From: tbr@aphrodite (Tim B. Robinson) 
To: bobm@aphrodite 

Subject: forwarded message from Richard Dickson 
Content-Length: 1 102 

Did the document get updated to track this on? 
Tim 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["215" "Mon" "10" "October" "1994" "21:10:50" "-0700" "Richard Dickson" "dickson@gamorra " nil "9" 
"euterpe/verilog/bsrc/ce cerbtempreg.V" " A From;" nil nil "10"]) 
Return-Path: <dickson@gamorra> 

Received: from gamorra.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA22417; Mon, 10 Oct 94 21:07:56 PDT 
Received: from localhost by gamorra.microunity.com (8.6.4/muse-sw.2) 

id VAA22129; Mon, 10 Oct 1994 21:10:50 -0700 
Message-Id: <1 994101 10410. V A A22 12 9@gamorra.microunity.com> 
From: dickson@gamorra (Richard Dickson) 

To: euterpe-checkins-dist@gamorra, lisar@gamorra, tbr@gamorra, tom@gamorra 
Subject: euterpe/verilog/bsrc/ce cerbtempreg.V 
Date: Mon, 1 0 Oct 1 994 2 1 : 1 0:50 -0700 

Update of /p/cvsroot/euterpe/verilog/bsrc/ce 

In directory gamorra:/N/rama/root/s5/dickson/euterpe/verilog/bsrc/ce 

Modified Files: 

cerbtempreg.V 
Log Message: 
power on defaults reg3 1 
<47:43>=00101 <39:35>=01010 

End of forwarded message 


End Included Message 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Friday, October 14, 1994 2:27 PM 
•Bill Zuravleff 

'Curtis Abbott'; 'euterpe@melpomene'; 'Scott Furman'; 'Guillermo A. Loyola'; 'Lisa Repka' 
D cache miss penalty, reality check 


Bill Zuravleff wrote (on Fri Oct 14) : 


Y'all, 


Now that we've done (one) d- cache fill on the euterpe logic model, 
the miss penalty can be *measured* and not just estimated. 
The miss penalty, filling from DRAM, is 400 ticks = 80 major cycles 
= 80 issue slots. 

Pertinent system parameters: 

1) sofa clock freq./DRAM clock freq = 13. 

This is based on 1 . 3GHZ/100MHz . Obviously, both of these frequencies 
may be wrong . 

2) NB (non-blocking load buffer) is empty at time of cache line request. 

3) Both DRAM banks are precharged. 

Where do all the cycles go? 

OK, to squeeze 64 bytes out of DRAM takes 16 DRAM clocks. 

There's an additional 3 DRAM clocks to ACTIVATE and (2 plus 

a fraction, call it) 3 of read latency. That's (16+3+3) *13 = 288 ticks 

of latency through DRAM. The rest is "overhead" and can be accounted 

for as follows (this is measured off of a simulation trace) . 

11 - from Miss to first NB request 

10 - through NB to Peripheral Broadcast Bus 

2 2 - through Peripheral Broadcast Bus, DRAM Controller, and sync to DRAM clock 
280 - through DRAM 

6 - back through controller, arbitrate for Peripheral Return Bus 

3 6 - back through NB, back through datapath pipeline, tag update 

3 5 - original load is rescheduled (original load is continually rescheduled 
on a 50 tick cycle, eventually it hits) . 


Reasons the Miss Penalty may increase: 

1) Other non-blocking loads/store in NB queues; particularly 

1/s to DRAM; particularly high priority requests to DRAM ; In particular, 
since cache line requests are serviced at low priority and the normal 
operating mode of euterpe is with NB full -- some of which are high 
priority DRAM requests -- the cache line request is likely to be 
delayed significantly. It's possible for the cache line request to 
wait forever behind high priority requests to DRAM sent by other threads. 

2) Correct DRAM bank is ACTIVE on wrong page. 

3) There are numerous points where data has to "sync to a beat": 

a) pbb (l of 4 beat) 

b) DRAM (1 of 13 beat) 

c) prb (1 of 4 beat for frame, 1 of 5 beat for frame within arbitration super- frame) 

d) returned NB load (1 of 2 0 beat) 
3) rescheduled Miss (1 of 50 beat) 

Sometime you're lucky, sometimes you're not. 

Reasons the Miss Penalty may decrease : 

1) Faster DRAM or lower sofa freq/ dram clock freq ratio. 

2) Correct DRAM bank is ACTIVE on correct page. 

Realistically I think we should assume 1080MHz for Euterpe and 83MHz for the DRAM. 


400 
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Hope this is somewhat in accord with simulator. 
Please holler if you think there's something wrong. 

What is the breakdown of the 50 tick beat to reschedule the miss? 

We anticipate the I -cache miss penalty to be greater. 

billz 
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From: Tom Karzes [karzes@MicroUnity.com] 

Sent: Friday, October 14, 1994 6:38 PM 

To: 'g mo@MicroUnity.com' 

Cc: 'abbott@MicroUnity.com' 

Subject: assembler/simulator bug status 


Some of the simulator bug I reported yesterday have been fixed. 

However, some were 1 1 fixed, and some of the fixes didn't correct all cases. 

Here ' s the current status : 


rotate 

passed 

expand 

passed 

compress 

passed 

extract 

aborts; missing opcodes for group size 1 

field 

failed 

copy swap 

passed j 

shuf f lemux 

passed |. 

select 

passed I 


Note that the extract test aborted part way through. It looks like the group size 1 fix 
isn't working properly. There could very well be additional gextract bugs which we aren't 
seeing because the test isn't making it that far. 

Of the tests which did run to completion, there are 2 failing opcodes: 

GDEPI 
GWTHI 

One failing example for both opcodes is when imml = imm2 = 0x38, 
i.e., the group size is 8, the shift amount is 0, and the field 
size is 1. Both opcodes should simply sign extend each byte 
from the low- order bit of that byte. These operations are failing 
in a non- obvious way. 

Look at -karzes/mysof t/stb/terp- src/stb/stand/diag/xlu . c for examples of each of these 
errors . 

Let me know when you think these bugs are fixed and I'll rerun my tests. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Fred Obermeier [fwo@pelagon] 
Friday, October 14, 1994 10:53 PM 
'geert@pelagorV; 'rich@pelagon'; 'tvo@pelagon' 
'fwo@pelagon' 
Euterpe S.t. changes 


Geert , 


As you have requested, I've move some of the OBS3 and OBS4 around in vdda_j?artition . ly so 
that the space transformer MS 3 vdda cuts should now be correct as described by Rich 
McCauley . 

I've also had to add a dependancy in the proteus/baseplate/Makef ile.base so that a change 
to vdda_partition would actually cause the space transformer to be properly rebuilt. I 
did this by making baseplate_apwr_only . ly dependent on vdda_partition. I've checked this 
change in under CVS; however, I have NOT done a releasebom of proteus/baseplate . 

Therefore, someone needs to do a releasebom of proteus/baseplate and so that the space 
transformer in /u/chip/euterpe/compass/baseplate can be rebuilt by running "gmake all" or 
"gmake spacetrans" under /u/chip/euterpe/baseplate as the user, chip. 


Fred. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Friday, October 14, 1994 11:06 PM 
'brianl@nosferatu' 
'tom@nosferatu'; 'geert@nosferatu' 
your leafgen spice simulations ... 


Seemed to have finished. 

The chipq is empty and there are no chip owned spice jobs ruunning. 
Since they were not expected to complete before tomorrow pm 

chipq 

The chip queue is empty. 

lisar@rhodan /s3/euterpe/verilog/bsrc 418 % hspicelic . . . Running metalicense -a on rhea 

user product token status type hostid/name class time 

Id. so: warning: /usr/lib/libc . so. 1 . 6 . 1 has older revision than expected 8 

21:02:24 1539: installdir environment variable should be set for licensing 

arya gsi 8 993 in_use SJF aphrodite 99 268:30:35 

bpw gsi 16386 in use SJF frodo 99 11:55:13 


Lisa R. 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, October 15, 1994 12:19 AM 
'euterpe@aphrodite'; 'hardheads@aphrodite' 
euterpe tapeout 


Euterpe tapeout is 


now underway in earnest 


vant wrote (on Fri 


Oct 14) : 


Earlier today (this morning about 9:30), I locked down all layouts used 
in the baseplate. With a few exceptions, this is the final version of 
the baseplate. 

Final DRCs are being started. The last runs were clean but did not include the PLL. We 
expect the new runs to be clean and completed in 

5-7 days. At that point we will begin fracturing the non-metal layers with the goal of 
having tapes ready for release for maskmaking by 10/31. 

There is still much to do in the metal layers, but we are turning up the heat to get all 
the logic completed by the 10/31 date also so that final GARDS routing and verification 
can start. 


Tim 
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From: vant [vanthof@hestia] 

Sent: Saturday, October 1 5, 1994 12:45 AM 

To: Tim B. Robinson' 

Cc: Vanthof ©aphrodite 1 ; 'tom@aphrodite' 

Subject: Re: DRC 

Tim B. Robinson writes: 

> 
> 

>How are we doing on moving parts of the DRC flow over to vlsimm? 

> 

>Tim 

> 

I have the drc flow converter so it now can read/write an ISS drc flow for us. 
This is a major step towards getting the tool to split out the drc flows. 
It does not support all the commands available, but enough to convert our 
drc flow. It does not support writing lvs commands yet, but it's not 
necessary at this time. 

The next phase (in my spare time), I need to build up a dependancy tree 
for the commands which can be converted to the various formats and then 
create the flows based on this dependancy tree. This is/will be a bit 
difficult as I've never done this before, however, I feel it should not 
be a tremendous amount of work. Once the dependany tree is build, then I 
can write out a vlsimm flow and a (iss j| dracula) flow with it. 

Regarding your previous email about the euterpe tapeout, I was informed by 
Kurt late today that the PLL won't be ready until monday... sigh. I had 
planned on starting the fullchip checks then. 

Evidently, after I had locked down the baseplate, there were 6 cells Rich 
needed unlocked to finish the pll. once those are done, I can lock them back 
down and start the verification. 

Thanks, 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) AH kids love Log! #incluce <std_disclaim.h> 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Saturday, October 15, 1994 12:50 AM 

To: 'euterpe@aphrodite' 

Subject: Data path crunch 


We are reaching a point where it's clear we can't quite cram everything into the main 
euterpe data path. We have a shortfall of about 20K atoms. We are running a routing 
experiment this weekend on a version in which we have deleted the 4bit group 
add/subtract/multiply operations. This looks like it will save around 15K, but the 
savings may be greater as other logic is expected to power down because of the reduced 
loading and area of the remaining logic. 

If this experiment is successful in making the datapath fit we will want to move rapidly 
to make this change permanent. Curtis has indicated that this is not likely to have any 
impact on the set top application. (Note there is no change to any XLU fuctionality . It 
will continue to support all operand sises down to 1 bit) . 

Please speak now if 

a) You believe there will be a significant negative software impact from this omission. 

b) You have alternative suggestions as to what else you would prefer to lose first. 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@boreas] 
Saturday, October 15, 1994 12:59 AM 
Vant@boreas'; Thomas Laidig'; 'Kurt Wampler' 
Tim B. Robinson'; 'Geert Rosseel' 
de-perfing castor, pollux and calliopO 


I had a brief conversation with Paul this evening. He suggests, if 
a) CPU is available and b) it is fairly easy, that we de-perf castor and pollux (I think 
only pad cells may be involved on castor) and fracture them and then hold the results. He 
was also interested in de-perf ing calliopeO, but that is lower priority. They are not yet 
sure how the de-perf ing experiments will turn out, so he is not pushing this strongly. 
On the other hand, if we do want to de-perf now may be the time to do it {rather than a 
month from now when we will be in the midst of tapeout) . 

My understanding is that de-perfing Castor and Pollux should not be too tough and 
relatively easy on CPU (I guess we would DRC both, and LVS 
one?) 


Comments? 


- thanks , 
hopper 
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From: tbr 

Sent: Saturday, October 15, 1994 1:00 AM 

To: Vant' 

Cc: 'torr^aphrodite'; Vanthof@aphrodite' 

Subject: Re: DRC 
Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Fri Oct 14): 

Tim B. Robinson writes: 

> 
> 

>How are we doing on moving parts of the DRC flow over to vlsimm? 

> 

>Tim 

> 

I have the drc flow converter so it now can read/write an ISS drc flow for us. 
This is a major step towards getting the tool to split out the drc flows. 
It does not support all the commands available, but enough to convert our 
drc flow. It does not support writing lvs commands yet, but it's not 
necessary at this time. 

The next phase (in my spare time), I need to build up a dependancy tree 
for the commands which can be converted to the various formats and then 
create the flows based on this dependancy tree. This is/will be a bit 
difficult as I've never done this before, however, I feel it should not 
be a tremendous amount of work. Once the dependany tree is build, then 1 
can write out a vlsimm flow and a (iss || dracula) flow with it. 

Thanks, sounds like good progress. 

Regarding your previous email about the euterpe tapeout, I was informed by 
Kurt late today that the PLL won't be ready until monday... sigh. I had 
planned on starting the fullchip checks then. 

Yes, I just had a rather grumpy reply from rich who is still there 
working with Kurt. Graham had told him he had till Sunday and he was 
upset there had been no warning. 

Evidently, after I had locked down the baseplate, there were 6 cells Rich 
needed unlocked to finish the pll. once those are done, I can lock them back 
down and start the verification, 

He is under the impression the gardswart has to fully rebuild before 
you can proceed. Is that really the case or is just the gardwart 
baseplate enough? 

Tim 
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From: vant [vanthof@hestia] 

Sent: Saturday, October 15, 1 994 1 :06 AM 

To: Tim B. Robinson' 

Cc: Thomas Laidig*; 'Dave Van't Hof ; 'Mark Hofmann' 
Subject: Re: DRC 

Tim B. Robinson writes: 

> 

>Yes, I just had a rather grumpy reply from rich who is still there 
>working with Kurt. Graham had told him he had till Sunday and he was 
>upset there had been no warning. 

> 

> Evidently, after I had locked down the baseplate, there were 6 cells Rich 

> needed unlocked to finish the pi I. once those are done, I can lock them back 

> down and start the verification. 

> 

>He is under the impression the gardswart has to fully rebuild before 
>you can proceed. Is that really the case or is just the gardwart 
>baseplate enough? 

> 

>Tim 

> 

If they can guarantee that no lower layers are edited, then all that's needed 
for DRC's is the baseplate. But I need someone (T. Vo) to place it in euterpe 
and generate a top level layout. 

For LVS'ing the baseplate, then yes, the entire gardswart must be rebuilt. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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From: vant [vanthof@hestia] 

Sent: Saturday, October 15,1 994 1.19 AM 

To: 'Mark Hofmann' 

Cc: , vant@boreas'; 'tom@boreas'; 'wampler@boreas'; 'tbr@boreas'; 'geert@boreas' 

Subject: Re: de-perfing castor, pollux and calliopO 


Mark Hofmann writes : 


> I had a brief conversation with Paul this evening. He suggests, if 
>a) CPU is available and b) it is fairly easy, that we de-perf castor 
>and pollux (I think only pad cells may be involved on castor) and 
fracture 

>them and then hold the results. He was also interested in de-perfing 
>calliopeO, but that is lower priority. They are not yet sure how the 
>de-perfing experiments will turn out, so he is not pushing this strongly. 
>0n the other hand, if we do want to de-perf now may be the time to do 
>it (rather than a month from now when we will be in the midst of tapeout) . 

I'm not sure where the castor/pollux layouts are located, but if I find them then I'll 
start up a test hole filling for them. The amount of work involved in fixing calliopeO is 
much more than what I expect for castor and pollux. 


> My understanding is that de-perfing Castor and Pollux should not be 
>too tough and relatively easy on CPU (I guess we would DRC both, and 
>LVS 
>one? ) 

DRC 1 s will be runm for any chip with it's holes filled, however, I don't remember what the 
state was for running LVS on castor/pollux. I thought there was no one top level netlist 
for either chip, but many smaller blocks. 

There has been no evidence of any LVS problems resulting from the automated hole filling 
script. Therefore, if we can get pollux/castor fixed by using the auto-hole-filling only, 
then I don't believe any LVS run is needed. We can attempt a shorts check, but that would 
be about it . 

Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

what's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! # inc luce 

<std disclaim. h> 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Saturday, October 15, 1994 1:19 AM 
'Curtis Abbott' 

'craig^Jtallis'; 'euterpe'; 'dickson@tallis' 
ggfmul8 


Follow Up Flag: Follow up 
Flag Status: Red 

We have implemented this change. In addition to doubling the 
performance of the ggfinul8 case there was the bonus of a small (but 
welcome) area saving of about 1000 atoms. ggfrnu!64 is no longer 
supported. 

Curtis Abbott wrote (on Wed Oct 12): 

Richard and I talked this morning about the problem alluded to in 
my response to Brendan's message, included below. Richard tells me 
that ggfmul8 goes from 1 to 2 ticks per bit (i.e. from 2 to 3 gate 
levels) when the muxes are included to also do ggfmul64. My response 
to that is let's drop ggfrnul64 from this implementation. I need 
ggfmul8 to be as fast as possible, but the performance of ggfrnul64 is 
not at all critical, since we can do CRC32 (the only real use I know 
of for ggfmul64 right now) pretty fast with table lookups in 8 bit 
whacks. Plus we're not doing nearly as many of them as ggfmuI8's. 


My mail of this morning to tbr, dickson, brendan, gmo: 

Brendan Eich wrote (on Tue Oct 1 1): 

Talked to dickson and he said ggfmul8 was likely to be microcoded using 
only a few bits of shift-xor per minor cycle. He estimated 40 ticks of 
latency and total hogging of the unit itself (which is fine) and of the 
issuing cylinder's pipe access (not so fine). So the simulator should be 
revised from its current wildly optimistic 4-cycle latency, 2 extra issue 
slots, to 8 and 7 respectively. 

This adds roughly 50% to the cost of the Reed- Solomon syndrome computation, 
which is in third place at 8.74% of cylinder 3 currently: 

% cumulative self self total 

time cycles cycles calls cy/call cy/call name 

61.35 5526624 5526624 5757 960 960 cable_in_handler 

13.05 6702053 1 175429 mpeg2_in_handler 

8.74 7489372 787319 320 2460 2460 rs_compute_syndrome 

4.53 7897877 408505 check_events 

2.88 8157083 259206 do_events 

I have a problem with this. I thought we were going to build 8 of the 
byte-wide units which would take 8 minor ticks, for a total of 16 per 


Curtis 
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ggfmul8 plus overhead. What's changed? 
- Curtis 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Saturday, October 1 5, 1 994 1:19 AM 

To: 'Curtis Abbott' 

Cc: 'craig@tallis'; 'euterpe@aphrodite'; 'dickson^allis' 

Subject: ggfmu!8 


We have implemented this change. In addition to doubling the performance of the ggfmul8 
case there was the bonus of a small (but 

welcome) area saving of about 1000 atoms. ggfmul64 is no longer supported. 

Curtis Abbott wrote (on Wed Oct 12) : 

Richard and I talked this morning about the problem alluded to in 
my response to Brendan's message, included below. Richard tells me 
that ggfmuls goes from 1 to 2 ticks per bit (i.e. from 2 to 3 gate 
levels) when the muxes are included to also do ggfmul64 . My response 
to that is let's drop ggfmul64 from this implementation. I need 
ggfmuls to be as fast as possible, but the performance of ggfmul64 is 
not at all critical, since we can do CRC32 (the only real use I know 
of for ggfmul64 right now) pretty fast with table lookups in 8 bit 
whacks. Plus we're not doing nearly as many of them as ggfmul8's, 

- Curtis 


My mail of this morning to tbr, dickson, brendan, gmo: 

Brendan Eich wrote (on Tue Oct 11) : 

Talked to dickson and he said ggfmuls was likely to be microcoded using 
only a few bits of shift-xor per minor cycle. He estimated 40 ticks of 
latency and total hogging of the unit itself (which is fine) and of the 
issuing cylinder's pipe access (not so fine). So the simulator should be 
revised from its current wildly optimistic 4 -cycle latency, 2 extra issue 
slots, to 8 and 7 respectively. 

This adds roughly 50% to the cost of the Reed- Solomon syndrome computation, 
which is in third place at 8.74% of cylinder 3 currently: 


% cumulative 

self 


self 

total 

time cycles 

cycles 

calls 

cy/call 

cy/call 

61.35 5526624 

5526624 

5757 

960 

960 

cable in handler 





13.05 6702053 

1175429 




mpeg2 in handler 





8.74 7489372 

787319 

320 

2460 

2460 

rs compute syndrome 





4.53 7897877 

408505 




check events 





2.88 8157083 

259206 




do events 






I have a problem with this. I thought we were going to build 8 of the 
byte-wide units which would take 8 minor ticks, for a total of 16 per 
ggfmuls plus overhead. What's changed? 

- Curtis 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Fred Obermeier [fwo@pelagon] 
Saturday, October 15, 1994 1:54 AM 
'geert@merope'; 'rich@merope'; , vo@merope' 
'fwo@pelagon' 
Re: vdda_partition 


Tom, 


Thanks for spotting this. 

I did a cvs update of euterpe/ compass , did the check out, mods and check in under compass. 
Now I see that my changes have not made it into the /u/chip version, and are still stuck 
in /u/f wo/chip/euterpe/compass/layouts/ . 

vlsi.log says that everything went ok, but cvs diff shows that these changes have not been 
checked in. The diff also shows that my version of vdda_partition. ly does not include the 
instance of f loorplan. ly , 

Maybe this situation is related to the new requirement of having mdunit in my vlsi.boo 
search path. 

Anyway, I'll add in the instance of the floorplan to my copy of vdda_parition, rebuild my 
local version of the baseplate and space transformer. If this looks ok, I'll try to cvs 
check this in manually. 

This is so confusing, but Geert seemed rather anxious about this fix. 


Fred. 
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From: Fred Obermeier [fwo@pelagon] 

Sent: Saturday, October 1 5, 1 994 2: 1 2 AM 

To: 'geert@merope'; 'rjch@merope'; Vo@merope' 

Cc: 'fwc^pelagon' 

Subject: Re: vdda_partition 


I've checked in my version of vdda_partition. ly, but have not done a releasebom . If you 
need to see this new version in /u/chip, please do a cvs update, and releasebom in 
euterpe/ compass /layouts . 

Fred. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope3 

Saturday, October 15, 1994 10:16 AM 

'Fred Obermeier' 

'geert@merope'; 'ricrKgmerope'; 'fwo@pelagon' 
Re: vdda_partition 


Fred Obermeier wrote .... 
> 

>Tom, 
> 

>Thanks for spotting this. 

>I did a cvs update of euterpe/ compass , did the check out, mods and 

>check 

in 

>under compass. Now I see that my changes have not made it into the 
/u/chip 

>version, and are still stuck in /u/f wo/ chip/euterpe/ compass /layouts/ . 
>vlsi.log says that everything went ok, but cvs diff shows that these 
changes 

>have not been checked in. The diff also shows that my version of 
>vdda_partition. ly does not include the instance of f loorplan. ly . 

> 

>Maybe this situation is related to the new requirement of having mdunit 

>in my vlsi.boo search path. 

> 

>Anyway, I'll add in the instance of the f loorplan to my copy of 
vdda_parition, 

>rebuild my local version of the baseplate and space transformer. If 
>this looks ok, I'll try to cvs check this in manually. 

The version in /u/chip/euterpe has the floorplan by mistake , 
The version in /u/chip/mdunit /euterpe has that corrected but was not 
released . Now , there's your version on top of all that . 
Anyway , I don't think you want to include floorplan 


>This is so confusing, but Geert seemed rather anxious about this fix. 


> 


>Fred. 


Tom Vo 


vo@microunity . com 


(408) 734-8100 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tom Vo [vo@merope] 

Saturday, October 15, 1994 10:33 AM 

'Fred Obermeier' 

'geeiKgmerope'; 'rich@merope'; 'fwo@pelagon'; Thomas Laidig' 
Re: vdda_partition 


Fred Obermeier wrote .... 
> 

>I've checked in my version of vdda_j?artition. ly, but have not done a 
>releasebom. If you need to see this new version in /u/chip, please do 
>a cvs update, and releasebom in euterpe/compass/layouts . 
> 

>Fred. 


I think I need to talk to Laidig first . 

This is what I believe Tom had in mind for the COMPASS check in/out the procedure : 

1. Have /u/chip/mdunit in your vlsi.boo path 

2 . Do a normal COMPASS check out , edit , then COMPASS checkin 

3 . Wait for his layout deamon to do a cvs check in from 
/u/chip/mdunit to /u/chip- archived then 

4 . Releasebom from /u/chip/mdunit for the results to show up in 


I'm not certain how you do your check out/ in , but the version in /u/chip/mdunit looks old 
still , and I'm not sure if I should do manual a cvs update in this directory while his 
deamon is doing stuffs in there . 


/u/chip . 


tvo 
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Sent: 
To: 

Subject: 


From: 


tor 

Saturday, October 15, 1994 11:08 AM 

'dickson* 

csyn problem 


Follow Up Flag: Follow up 
Flag Status: Red 


The fix in mc doesn't seem to have taken fully; 


Topmost net has 2 different mpvs: 

Found 2 different p- values: 1, 0 

Found 1 different p- range values: m 

instance path: top.xlrs!tr9_3 1 

cellname path: top.xlrsltr9_3 1 
leaf connections: 

instance path: top.xxlug_ctrldatag_q_9ag_q_9a_3 l_95p0_4p_l .xlrsltr9_3 1 
cellname path: top.scsmf3rv3 .is3_alph 
instance path: top.xmcu2 14ul 5.xlrsltr9_3 1 
cellname path: top.xbhrdh2s .d0_ad0ph 

in stance path : top . xxlug_ctr ldatag_q_9ag_q_9a_3 1 _9 5p0 1 p_ 1 .x lrsltr9_3 1 
cellname path: top.scsof3v3 ,d4_adlph 
instance path : top.xrgursltupr9u3 1 ,xlrsltr9_3 1 
cellname path: top.xbbufdh8s .d0 admph 

instance path: top.xxlug_ctrldatag_q_9ag_00 l_95p0_3p_l .xlrsJtr9_3 1 
cellname path: top.scsmf3v3 .sisl_alph 
instance path: top.xmcu01u03uOOu7.xlrsltr9_31 
cellname path: top.xbmuxff2dh2s .dO adOph 


There are several cases like this, but it does not seem to affect all 
the bus. (Look in my bsrc/tbr_euterpe-passl .csyn for the full log). 


Tim 
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To: 


Sent: 


Subject: 


From: 


for 

Saturday, October 15, 1994 11:13 AM 
'fwo' 

csyn problem 


Follow Up Flag: Follow up 
Flag Status: Red 

The fix for the reg file problem seems to have worked in my latest 
run. 

At the end I get the following. Any idea what it's trying to tell me? 

passed SingleEndedlnputNodeSwingCheck 
passed ExclusivelnputSetCheck 
passed ExdusivelnputSwingCheck 
passed DifflnputNodePairCheck 

error (DiffInputNodeSwingCheck.712) in file "tbr_euterpe-passl. spivs": drivers are non-diff or fail leaf-inp swing 
requirements 

** failed DifflnputNodeSwingCheck 


Tim 
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From: Geert Rosseel [geert@ambiorix] 

Sent: Saturday, October 15, 1994 12:50 PM 

To: 'bpwOambiorix'; 'solo@ambiorix'; 'stick@ambiorix' 

Cc: 'tbr@ambiorix' 

Subject: Planning, schedule , etc ... 

Hi, 

In order to build the development workstation that simultaneously 
will allow us to meet the conversion ratio, we need to build two 
chips : 

A Mnemosyne in MoBIMOS 
A Euterpe in an outside foundry. 

In both cases, the logic design will change as little as possible 
from the existing designs. Building a Mnemo is a relatively easy 
job (it is planned to be the same padring/size as Calliope/Euterpe 
and mostly the same building blocks the current Euterpe). 

The pressure on finishing a Mnemo is very high. Once we have a 
Mnemo, we can build a workstation with the current Euterpe. Later, 
we can then swap our Euterpe with the outside Euterpe. 

We'de like to finish a Mnemo by the end of the year (1 994). 
Alan and Tim believe that logic design & GARDS placement is 
possible within the next two months. In term of custom designs, 
we will need : 

1 . A memory block : suggestions range from a CMOS version 
of the current caches ( to save power) to a remap of 

the original Mnemo memory block : Tim will call a 
meeting on Monday (I'll be out on Monday) to discuss 
the options. 

2. A stronger TTL DRAM I/O driver / Mnemo has to drive a 
lot more memory than Euterpe. 

3. A PCI bus driver ... Alan has a description of the specs 
of that driver ... 

We'de like to have the three above designs finished by the 
middle of December (fuly layed out and verified). 

In the mean time, we'll set up the foundry infrastructure 
so that we can starting designing Euterpe II by Jan 1995. 

Please, see Tim or Alan for logical specifications for the 
above blocks. 


Geert 
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From: tbr 

Sent: Saturday, October 15, 1994 1:19 PM 

To: 'Geert Rosseel' 

Cc: 'bpw@ambiorix'; 'age'; 'solo@ambiorix'; 'stick@ambiorix' 

Subject: Planning, schedule , etc ... 


Follow Up Flag: Follow up 
Flag Status: Red 


Geert Rosseel wrote (on Sat Oct 1 5): 


Hi, 

In order to build the development workstation that simultaneously 
will allow us to meet the conversion ratio, we need to build two 
chips : 

A Mnemosyne in MoBIMOS 
A Euterpe in an outside foundry. 

In both cases, the logic design will change as little as possible 
from the existing designs. Building a Mnemo is a relatively easy 
job (it is planned to be the same padring/size as Calliope/Euterpe 
and mostly the same building blocks the current Euterpe). 

The pressure on finishing a Mnemo is very high. Once we have a 
Mnemo, we can build a workstation with the current Euterpe. Later, 
we can then swap our Euterpe with the outside Euterpe. 

We'de like to finish a Mnemo by the end of the year (1994). 
Alan and Tim believe that logic design & GARDS placement is 
possible within the next two months. In term of custom designs, 
we will need : 

We do need to add support for the PCI bus in order to get access to 
Ethernet, SCSI and RGB display cards. This is the highest risk part. 

1 . A memory block : suggestions range from a CMOS version 
of the current caches ( to save power) to a remap of 
the original Mnemo memory block : Tim will call a 
meeting on Monday (I'll be out on Monday) to discuss 
the options. 

A major issue to be decided is if we need any form of redundancy. 
The way the redundancy was implemented in Mnemosyne means that if we 
so decide, we could eliminate it with virtually no change to the logic 
design. It's not clear to me if we use our existing Euterpe RAM 
technology we can easily get meaningful block level redundancy. 

Another concern is power consumption. We expect to have 6 of these 
Mnemosyne devices int the box (4 controlling DRAM, 2 acting as Hermes 
to PCI bridges). Total power dissipation will be an issue so we don't 
make the box thermal design a nightmare. However, we do not need such 
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aggressive read performance as we have in Euterpe. 
Let's meet 10am Monday to discuss this. 

2. A stronger TTL DRAM VO driver / Mnemo has to drive a 
lot more memory than Euterpe. 

We do not need such a fast edge rate as we have on Euterpe. We should 
see how what we have now compares to the driver in the old Mnemosyne 
under similar loading conditions which 1 seem to remember was 200pF. 

3. A PCI bus driver ... Alan has a description of the specs 
of that driver ... 

We will need to address the 3.3 to 5V issue on this one. Although 
there is a transition map defined for PCI to migrate from 5V to 3.3V 
I do not think there are many (if any) PCI cards available yet for 
3.3V operation. We want to choose the cards we will be using in the 
next week so the software group can start work on drivers using a 
pentiam based PCI system. 

We'de like to have the three above designs finished by the 
middle of December (filly layed out and verified). 

In the mean time, we'll set up the foundry infrastructure 
so that we can starting designing Euterpe II by Jan 1995. 

Please, see Tim or Alan for logical specifications for the 
above blocks. 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Fred Obermeier [fwo@pelagon] 
Saturday, October 15, 1994 1:35 PM 
'vo@merope' 

'fwo@pelagon'; 'geert@merope'; 'rich@merope' 
Re: vdda_partition 


Tom, 


I guess I should have sent another message last night saying that since the check- ed in 
version didn't have the floorplan instance, the one I checked in didn't either. I was 
getting pretty tired last night and really wanted to get to sleep. 

Anyway, I think the cvs stuff should be right. Someone will have to do one of those 
coordinated releaseboms to include the new stuff in 

proteus/baseplate/Makef ile .base 

eut erpe /compass/ layout s/vdd_part it ion. ly 


Thanks , 
Fred. 
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From: Tom Vo [vo@merope] 

Sent: Saturday, October 15, 1994 2:43 PM 

To: Tim B. Robinson'; 'Geert Rosseel'; 'Richard Dickson'; 'Alan Corry'; 'Mark Hofmann' 

Subject: euterpe update 


It's quiet now so I'm going to do a bunch of releases to get the chip version of the 
baseplate and gards updated . 

I'll send mail again when the releases complete 
tvo 
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From: Tom Vo [vo@merope] 

Sent: Saturday, October 1 5, 1 994 3:47 PM 

To: 'Geert Rosseel'; Tim B. Robinson'; 'Alan Corry'; 'Richard Dickson'; 'Mark Hofmann' 

Subject: euterpe release 


euterpe/baseplate , gards and clockbias in chip has been updated . 

The changes were : 

a new pll vdda plane to correct build the st . 
new padlist node name with the signal qualifier . 

tvo 
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From: Brian Lee [brianl@ghidra] 

Sent: Saturday, October 15, 1994 5:53 PM 

To: 'Lisa Robinson' 

Cc: 'brianl@nosferatu'; 'geert@nosferatu' 

Subject: Re: proteus build dies 


Lisa Robinson writes : 
/n/auspex/s4l/euterpe-proteus/proteus/makerrs4 

# This equation is ugly. We've measured the delay from 1/4 to 3/4 # of 
the exponential. Because tt2wave wants the twice the delay to # 1/2 
way, we have: 

# trf == 2*tau*log(2) = 2* (log (2) /log (3) ) * (tau*log (3) ) = 

# 2* (log{2) /log (3) ) *tau* (log(4) -log(4/3) ) = 

# 2* (log(2) /log (3) * (t.75 - t.25) 
nawk '$6 ~ /1.0/ { printf ( "s/op_trfhalf /%s/\n" , \ 

2*(log(2)/log(3))*($2-$D) ; \ 
printf ("s/op_trffull/%s/\n", \ 

2*(log(2)/log(3))*($4-$3)) }' \ 

slope. mtO > fix_tt.sed 
nawk: can't open slope. mtO 

source line number 1 
gmake[3]: *** [fix_tt.sed] Error 2 
graake[3] : Leaving directory 
* /N/auspex/root/s41/euterpe-proteus/proteus/spice/misc 1 

This is because 

/n/auspex/s41/euterpe-proteus/proteus/proteus/lpe/lobes/subckt . lpesp 

is bad. The make output for this file is in 

/n/auspex/s41/euterpe-proteus/proteus/makerrs2 

Unfortunately, this is the attempt that we terminated early, though it appears that there 
were problems before then anyways. 

Geert - will you look at this? 

Thanks , 

- - Brian 


Brian Lee brianl@microunity.com 
MicroUnity Systems Engineering (408) 734-8100 
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From: Lisa Robinson [lisar@nosferatuJ 

Sent: Sunday, October 16, 1994 12:19 AM 

To: 'brianl@nosferatu' 

Cc; 'geert@nosferatu' 

Subject: proteus build dies 


/n/auspex/s41/euterpe-proteus/proteus/makerrs4 

# This equation is ugly. We've measured the delay from 1/4 to 3/4 # of the exponential. 
Because tt2wave wants the twice the delay to # 1/2 way, we have: 

# trf == 2*tau*log(2) = 2* (log (2 ) /log (3 ) ) * ( tau* log ( 3 ) ) = 

# 2*(log(2)/log(3))*tau*(log(4)-log(4/3)) = 

# 2* (log(2) /log(3) * (t.75 - t.25) 
nawk '$6 ~ /1.0/ { printf ( "s/op_trfhalf /%s/\n" , \ 

2*(log(2)/log(3))*($2-$l)J; \ 
printf ("s/op_trffull/%s/\n" , \ 

2*(log(2)/log(3))*($4-$3)) }■ \ 

slope. mtO > fix_tt.sed 
nawk: can't open slope.mtO 

source line number 1 
gmake [3] : *** [fix_tt.sed] Error 2 
gmake[3]: Leaving directory 

VN/auspex/root/s41/euterpe-proteus/proteus/spice/misc 1 


Lisa R. 
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From: 


tbr 


Sent: 


Subject: 


To: 


Cc: 


Sunday, October 16, 1994 10:45 PM 
"Lisa Robinson' 

'doi@nosferatu'; 'hopper@nosferatu'; 'tom@nosferatu' 
doi.verilog 


Follow Up Flag: Follow up 
Flag Status: Red 

Lisa Robinson wrote (on Thu Oct 6): 

Can we get this verilog installed in the right place. 
This is the KLUDGE put into euterpe/veriog/bsrc 
DOIVERILOG - 

LM_LICENSE_FILE=$(CHIPROOT)/tools/vendor/cadence/share/license/license.55000dbe /u/doi/src/hermes/doi. verilog 

Yes as Tim pointed out I could have just redefined VERILOG_PROG but 
since that would have meant that all of the verilog targets used this 
ie everyone typing bsim I felt that it should be installed correctly. 

Did this get done? 


Tim 
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From: tbr 

Sent: Monday, October 17, 1994 12:53 AM 

To: 'Mark Hofmann' 

Cc: 'Mark Semmelmeyer'; 'Geert Rossee!'; Vant@tomato' 

Subject: checking clock phases 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hoftnann wrote (on Fri Oct 14): 


There's been some concern that clock phases are correct on the Euterpe 
designs. The "gloss" tool can be used to check this. Before I make a wider 
announcement I was looking for some guinea pigs that might want to try things 
out. 

To check a design: 

1. topt -e <design>.edif -K <deisgn>.strength -o out.edif \ 

-g/u/chip/proteus/leafgen/toptList 

2. edif2gloss out.edif <design> 

3. gloss -clocks phi_a2p phH>2p -phaseCheckOnly out >& <design>.log 
Check <design>.warn for phase violations. 

Please ask if you have questions. 

NB: This does _not_ check the "tau" signals. Dave is looking at adding 
that capability into Topt. 

I ran it against the top level. Looks OK, but can you look over the 
files please? 


24952 -rw-rw-r- 1 tbr 255 1 83 1 0 Oct 1 6 22:33 euterpe/verilog/bsrc/gards/tbr_euterpe-pass 1 .flat 

224 -rw-rw-r- 1 tbr 214730 Oct 16 22:33 euterpe/verilog/bsrc/gards/tbr_euterpe-passl. delay 
1 -rw-rw-r- 1 tbr 190 Oct 16 22:39 euterpe/verilog/bsrc/gards/gloss.log 
1 -rw-rw-r— 1 tbr 631 Oct 16 22:39 euterpe/veri!og/bsrc/gards/tbr_euterpe-passl. out 

664 -rw-rw-r- 1 tbr 670565 Oct 16 22:39 euterpe/verilog/bsrc/gards/tbr euterpe-passl.warn 
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From: Tim B. Robinson [tbr@gamorra] 

Sent: Monday, October 17, 1994 12:53 AM 

To: 'Mark Hofmann' 

Cc: 'Mark Semmelmeyer'; 'Geert RosseeC; Vant@tomato' 

Subject: checking clock phases 


Mark Hofmann wrote (on Fri Oct 14) : 


There 1 s been some concern that clock phases are correct on the Euterpe 
designs. The "gloss" tool can be used to check this. Before I make a wider 
announcement I was looking for some guinea pigs that might want to try things 
out . 

To check a design: 

1. topt -e <design> . edif -K <deisgn> . strength -o out.edif \ 

-g / u / chip/proteus/ leaf gen/ toptList 

2. edif2gloss out.edif <design> 

3. gloss -clocks phi_a2p phi_b2p -phase Che ckOnly out >& <design> . log 
Check <design> . warn for phase violations. 

Please ask if you have questions. 

NB: This does _not_ check the "tau" signals. Dave is looking at adding 
that capability into Topt . 

I ran it against the top level. Looks OK, but can you look over the files please? 


24952 -rw-rw-r-- 1 tbr 25518310 Oct 16 22:33 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . flat 
224 -rw-rw-r-- 1 tbr 214730 Oct 16 22:33 

euterpe/verilog/bsrc/gards/ tbr_euterpe-passl . delay 

1 -rw-rw-r-- 1 tbr " 19 0 Oct 16 22:39 

euterpe/verilog/bsrc/gards/gloss . log 

1 -rw-rw-r-- 1 tbr ~ 631 Oct 16 22:39 

euterpe/verilog/bsrc/gards/ tbr_euterpe-passl . out 

664 -rw-rw-r-- 1 tbr 670565 Oct 16 22:39 

euterpe/verilog/bsrc/gards/tbr_euterpe -pass 1 .warn 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Mark Hofmann [hopper@tomato] 
Monday, October 17, 1994 6:45 AM 
Tim B. Robinson' 

'Mark Semmelmeyer'; 'Geert Rosseel'; Vant@tomato' 
Re: checking clock phases 


Tim B. Robinson writes: 

I ran it against the top level. Looks OK, but can you look over the 
files please? 

[snip] 
Okay. 

I looked at the results and it turns out that Gloss didn't run very long. 
I forgot to mention the " -multiclocks" option which is need for the full Euterpe chip 
(since cerberus is also a part of it) . At any rate, I re- ran with -multiclocks. The output 
file is 

~hopper/tools/src/gloss/examples/ tbr_euterpe-passl . warn 

There are 2997 phase warnings reported. All of these of these are at the boundary of 
cerberus and euterpe (as near as I can tell) where the phase checker has difficulty 
checking. These are probably okay. Could someone please have a look at these? Perhaps I 
can teach the phase checker about these situations. 

The good news is that there appear to be no real phase errors . 


- thanks , 
hopper 
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From: Mark Hofmann [hopper@boreasj 
Sent: Monday, October 1 7, 1 994 8:40 AM 
To: Tim B. Robinson' 

Cc: 'lisar@nosferatu'; 'doi@nosferatu'; 'hopper@nosferatu'; 'tom@nosferatu' 
Subject: Re: doi.verilog 

Tim B. Robinson writes: 
Lisa Robinson wrote (on Thu Oct 6): 
Can we get this verilog installed in the right place. 

This is the KLUDGE put into euterpe/veriog/bsrc 

DOIVERILOG = 

LM_LICENSE_FILE=$(CHIPROOT)/tools/vendor/cadence/share/license/license.55000dbe/u/doi/src/hermes/doi.v 

Yes as Tim pointed out I could have just redefined VERILOG_PROG but 
since that would have meant that all of the verilog targets used this 
ie everyone typing bsim I felt that it should be installed correctly. 

Did this get done? 
Tim 

Umm.. I'm not sure. Doi was also trying to do the build for the HP version 
so all our Verilogs were in sync. 

-hopper 
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From: Mark Hofmann [hopper@boreas] 

Sent: Monday, October 1 7, 1 994 8:46 AM 

To: Tim B. Robinson 1 

Cc: 'Mark Semmelmeyer'; 'Geert Rosseel'; 'vant@boreas' 

Subject: Re: checking clock phases 


Tim B. Robinson writes: 

I ran it against the top level. Looks OK, but can you look over the 
files please? 

24952 -rw-rw-r-- 1 tbr 25518310 Oct 16 22:33 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . flat 

224 -rw-rw-r-- 1 tbr 214730 Oct 16 22:33 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . delay 

1 -rw-rw-r-- 1 tbr 190 Oct 16 22:39 

euterpe/verilog/bsrc/gards/gloss . log 

1 -rw-rw-r-- 1 tbr 631 Oct 16 22:39 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl .out 

664 -rw-rw-r-- 1 tbr ~ 670565 Oct 16 22:39 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl .warn 


Okay. No errors reported. Cerberus clocks were not checked (That can be checked separately 
with another gloss run.) I want to do a little more poking around to make sure everything 
is okay, though. COuld you leave the files around for awhile? 

- thanks , 
hopper 
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From: Mark Hofmann [hopper@tomato] 
Sent: Monday, October 17, 1994 10:23 AM 
To: 'Tim B. Robinson' 
Cc: Tom Vo' 

Subject: Re: Phase check results on Euterpe (fwd) 

Tom Vo writes: 
Mark Hofmann wrote .... 
>Tom Vo writes: 

> Can't tell from this error because you're treat cgclockbias as one cell . 

> I think you need to expand down to the same level of csyn / celltest . 


> *** Warning: At least one output [qj>m, net cerba2_am] of cerbu02u09u59 [xclatbc - phase unknown] 

> connects to an input [dSadOph] 

> of iol infifoudoutuO [xbmuxff6dh2s - phi_a2p]. 

> Instance iol infifoudoutuO [xbmuxff6dh2s : flip-flop] driven by... 

> instance iolinfifoud5u0 [setoff] driven by... 

> instance iol infifoudmSuO [xbmux2dh3s] driven by . . . 

> instance iobytel [iobyte] driven by... 

> instance elk [cgclockbias] driven by... 

> instance cerbu00buf80a_J [ceinvx5] driven by... 

> instance cerbu00buf81a_l [ceinvxS] driven by... 

> instance cerbuOObuf82a_0 [ceinvxS] driven by... 

> instance cerbu01cga529 [ceinvx5] driven by... 

> instance cerbu01cga329_J [xcnand2c] driven by... 

> instance cerbu01zz81 [xcinvc] driven by... 

> instance cerbuO 1 zz59 [xcnand4c] driven by . . . 

> instance cerbu01zz39 [xcinvc] driven by... 

> instance cerbuOl zzl 8 [xcnand4c] driven by... 

> instance cerbu02u09u59 [xclatbc : latch]. 
> 

>Hmmm... The edif input that this was generated from treated cgclockbias 
>as a leaf cell- that is it called no other cells. Perhaps we could merge 
>in a more detailed model with emerge? What is the csyn/celltest level of 
>cgclockbias? 

> 

>-hopper 

Cgclockbias is a mix of cmos and eel circuits . For your purpose , it should 
not be considered a leaf cell . You need to expand downward until you hit 
a verilog property like csyn and celltest . 


Hi Tim, 

I'm not familiar with the recipe, but it appears that we need an Edif 
netlist of Euterpe which would be suitable for csyn/celltest and LVS. I think 
this means a call to emerge to expand the custom cells like cgclockbias, 
iobyte, etc. Could you generate a full chip Edif like that? Then I'll try 
another Gloss run. 

-thanks, 
hopper 
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From: Tom Laidig [tom@clio] 

Sent: Monday, October 17, 1994 10:28 AM 

To: Vant' 

Cc: 'hopper@boreas'; Vant@boreas'; 'tom@boreas'; 'wampler@boreas'; 'tbr@boreas'; 

'geert@boreas' 

Subject: Re: de-perfing castor, pollux and calliopO 


vant writes : 
Mark Hofmann writes: 


> I had a brief conversation with Paul this evening. He suggests, if 
>a) CPU is available and b) it is fairly easy, that we de-perf castor 
>and pollux (I think only pad cells may be involved on castor) and 
fracture 

>them and then hold the results. He was also interested in de-perfing 
>calliope0, but that is lower priority. They are not yet sure how the 
>de-perfing experiments will turn out, so he is not pushing this 
strongly. 

| >On the other hand, if we do want to de-perf now may be the time to do 

j >it (rather than a month from now when we will be in the midst of tapeout) . 

j I'm not sure where the castor/pollux layouts are located, but if I find 
them 

| then I'll start up a test hole filling for them. The amount of work 
| involved in fixing calliopeO is much more than what I expect for castor 
j and pollux. 

castor : 

/n/auspex/s2 8/castor-retry/castor/castor/compass/vlsi .boo- tapeout 
pollux: 

/n/auspex/s2 8/castor-retry/pollux/pollux/compass/vlsi -boo- tapeout 
calliopeO : 

/n/auspex/s2 8 /castor- retry/ calliope/calliope/compass/vlsi . boo- tapeout 
Note that each one has its own version of proteus. 


Tom L 
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From: tbr 

Sent: Monday, October 1 7, 1 994 1 1 : 08 AM 

To: 'Mark Hofmann' 

Cc: 'Mark Semmelmeyer'; 'Geert Rosseel'; 'vant@boreas' 

Subject: Re: checking clock phases 
Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Mon Oct 17): 

Tim B. Robinson writes: 
I ran it against the top level. Looks OK, but can you look over the 
files please? 

24952 -rw-rw-r- 1 tbr 25 5 1 83 1 0 Oct 1 6 22:33 euterpe/verilog/bsrc/gards/tbr_euterpe-pass I .flat 

224 -rw-rw-r- 1 tbr 214730 Oct 16 22:33 euterpe/verilog/bsrc/gards/tbr_euterpe-pass 1 .delay 

1 -rw-rw-r- 1 tbr 190 Oct 16 22:39 euterpe/verilog/bsrc/gards/gloss.log 

1 -rw-rw-r— 1 tbr 631 Oct 16 22:39 euterpe/verilog/bsrc/gards/tbr^euterpe-passl.out 

664 -rw-rw-r- 1 tbr 670565 Oct 16 22:39 euterpe/verilog/bsrc/gards/tbr_euterpe-pass 1 .warn 


Okay. No errors reported. Cerberus clocks were not checked (That can be 
checked separately with another gloss run.) T want to do a little more 
poking around to make sure everything is okay, though. COuld you leave 
the files around for awhile? 

Yes, will do. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Monday, October 1 7, 1 994 11 : 08 AM 

To: 'Mark Hofmann' 

Cc: 'Mark Semmelmeyer'; 'Geert Rosseel'; 'vant@boreas' 

Subject: Re: checking clock phases 


Mark Hofmann wrote (on Mon Oct 17) : 

Tim B . Robinson writes : 

I ran it against the top level. Looks OK, but can you look over the 
files please? 

24952 -rw-rw-r- 1 tbr 25518310 Oct 16 22:33 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . flat 

224 -rw-rw-r-- 1 tbr 214730 Oct 16 22:33 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . delay 

1 -rw-rw-r-- 1 tbr 190 Oct 16 22:39 

euterpe/verilog/bsrc/gards/gloss . log 

1 -rw-rw-r-- 1 tbr 631 Oct 16 22:39 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . out 

664 -rw-rw-r-- 1 tbr 670565 Oct 16 22:39 

euterpe/verilog/bsrc/gards/tbr_euterpe-passl . warn 


Okay. No errors reported. Cerberus clocks were not checked (That can be 
checked separately with another gloss run.) I want to do a little more 
poking around to make sure everything is okay, though. COuld you leave 
the files around for awhile? 

Yes, will do. 

Tim 
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From: Derek Iverson [doi@demeter] 
Sent: Monday, October 17, 1994 1 1:21 AM 
To: Tim B. Robinson' 

Cc: 'doi@nosferatu'; 'hopper@nosferatu'; 'Lisa Robinson'; 'tom@nosferatu' 
Subject: doi.verilog 

Tim B. Robinson writes: 

> Lisa Robinson wrote (on Thu Oct 6): 

> Can we get this verilog installed in the right place. 

> 

> This is the KLUDGE put into euterpe/veriog/bsrc 

> 

> DOIVERILOG - 

LM_LICENSE_FILE-$(CHIPROOT)/tools/vendor/cadence/share/license/license.55000dbe /u/doi/src/hermes/doi.verilog 

> 

> Yes as Tim pointed out I could have just redefined VERILOG_PROG but 

> since that would have meant that all of the verilog targets used this 

> ie everyone typing bsim I felt that it should be installed correctly. 

> 

> Did this get done? 
Almost. 

I have checked in two files (README. VERILOG. he and veriuser.c. portion) 
that should enable us to inlude the hermes model properly. I have 
build a HP version of verilog (veriloghe) and can start on a Sun 
version but need 'validmgr' to grant me access. 

doi 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Monday, October 17, 1994 11:29 AM 

Tom Vo' 

'fwo@pelagon'; 'geert@merope'; , rich@merope'; 'tom@merope' 
Re: vdda_partition 


Tom Vo writes : 

Fred Obermeier wrote .... 
> 

>I've checked in my version of vdda_partition. ly, but have not done a 
>releasebom. If you need to see this new version in /u/chip, please do 
>a cvs update, and releasebora in euterpe/ compass/ layout s . 
> 

>Fred. 


I think I need to talk to Laidig first . 

This is what I believe Tom had in mind for the COMPASS check in/out the 
procedure : 

1. Have /u/chip /mdunit in your vlsi.boo path 

2 . Do a normal COMPASS check out , edit , then COMPASS checkin 

3. Wait for his layout deamon to do a cvs check in from 
/u/chip/mdunit to /u/chip-archived then 

4. Releasebom from /u/chip/mdunit for the results to show up in 


That's correct. If the edit is being done using vi, replace steps 1 and 
2 with something that copies the file into /u/chip/mdunit. 


I'm not certain how you do your check out/in , but the version in 
/u/chip/mdunit looks old still , and I'm not sure if I should do manual 
a cvs update in this directory while his deamon is doing stuffs in 
there 


Could someone tell me exactly what _did_ happen? I think the daemon is supposed to update 
/u/chip/mdunit if it notices that another version has been checked in from somewhere 
else... oh, but only if the cell is unlocked; was it? Hmmm. . . the cell locking stuff 
kinda depends on everyone making all changes through /u/chip/mdunit... I wonder if there's 
some way to improve that . . . 

Anyway, if someone could describe exactly what did happen, I'd be interested. I may need 
to do some more work on the daemon. 


/u/chip . 


Tom L 
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From: 


tbr 


Sent: 


Monday, October 17, 1994 11:33 PM 


Subject: 


To: 


Cc: 


'Bruce Bateman' 
'geert@kephalos' 
Mnemo/Euterpe 


Follow Up Flag: Follow up 
Flag Status: Red 

Bruce Bateman wrote (on Mon Oct 1 7): 

I've been working on a CMOS version of the Euterpe cache. Is 

this now on hold? Mail sounds like we're going to use the 

current Euterpe instead of a new CMOS version for the comparison. 

Sorry about missing 10am meeting - life conspired against me. 
Will be in tomorrow. 

P.S. - 1995 ISSCC will have the P6, the new (620?) power-PC, 
the new DEC Alpha, and the HAL Sparc u-P. Should be quite 
a session. 

Comparison requires 2 implementations of Euterpe. Assumption is we 
have no choice but to use plain CMOS for the outside version. 

mouss has been saying that the spec/area performance of a MOBIMOS 
CMOS only version might be better than the performance of the BiCMOS 
version because area may go down faster than performance in switching 
to CMOS. Abolute performance is not the issue, only relative 
performance between an implementation on our process and the one on 
the outside process. 

The problem with this is that we then end up having to remap Euterpe 
twice not once. I resist that strongly, unless our analysis of the 
CMOS chip on the outside process suggests we cannot get a big enough 
advantage compared to the BiCMOS version. There is no point taking 
schedule risk going for more than we need. 

With regard to this morning's meeting, we were focussing there on the 
RAM we need in Mnemosyne. An issue is the power dissipation. We want 
1Mbit + tag + ecc, which makes it about 1 .5Mbit total. Bpw reconned 
we could do that easily with an array power of < 2W (very few writes) 
with a CMOS version derived from the old Mnemosyne design. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Bruce Bateman [stick@kephalos] 
Monday, October 17, 1994 1 1:57 AM 
'geert@kephalos'; 'tbr@kephalos' 
Mnemo/Euterpe 


I've been working on a CMOS version of the Euterpe cache. Is this now on hold? Mail 
sounds like we're going to use the current Euterpe instead of a new CMOS version for the 
comparison. 

Sorry about missing 10am meeting - life conspired against me. 
Will be in tomorrow. 

P.S. - 1995 ISSCC will have the P6 , the new (620?) power- PC, the new DEC Alpha, and the 
HAL Sparc u-P. Should be quite a session. 


BB 
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From: 
Sent: 
To: 

Subject: 


Paul Poenisch [paulp@acteon] 
Monday, October 17, 1994 4:11 PM 
'calliope@acteon' 

calliopeO/castor/pollux deperforation 


As you may know there has been a change in the way that the design rules are being applied 
to our current designs. We are now trying to minimize the number of minimum feature 
perforations in metal layers (0.5 by 0.5 um) . 
To 

do this the CAD group has written a program to remove these (and somewhat 
larger) holes from large metal sheets without changing the circuit topology. 

This procesure has been applied to orchis and calliopel. Reticles for orchis are now 
coming in but the tapes for the new version of calliopel are being held until we see the 
resutls on orchis (which is acutally ahead of 
calliopel 
in the fab) . 

There has been a great deal of discussion on the issue of going back and def erf orating 
calliopeO, castor and pollux. It appears that we will be doing this now. Currently 
Hopper is checking to see what the resource situation for doing this work is (we don't 
want to interfere with euterpe tapeout) . 
If 

there is sufficient resources available we will do all three chips, if there is a resource 
crunch it has been proposed to do only castor and pollux (castor has only one cell that 
would need to be modified so it shouldn't take much work) . 

The question we need to answer now is; are there any circuit blocks on calliopeO that we 
need test results on that are not on pollux? If so we will have to find the resources to 
fix calliope also. 

In either case we will hold the tapes for calliopeO/castor/pollux until orchis verifies 
the fix and we are reasonably sure that no additional changes are needed. 

Please resond in the next couple of days if you believe that we need to update calliopeO. 


Paul 


Exhibit C7 


Page 313 of 703 


Subject: 


Sent: 

To: 

Cc: 


From: 


vant [vanthof@hestia] 

Monday, October 17, 1994 4:23 PM 

'Paul Poenisch' 

'Dave Van't Hof ; 'Mark Hofmann'; 'Thomas Laidig'; 'Kurt Wampler'; 'Geert Rosseel' 
Re: call iopeO/castor/pol lux deperforation 


Paul Poenisch writes: 
> 

>As you may know there has been a change in the way that the design 

>rules 

are 

>being applied to our current designs. We are now trying to minimize 

>the number of minimum feature perforations in metal layers (0.5 by 0.5 urn). 

To 

>do this the CAD group has written a program to remove these (and 
> somewhat 

>larger) holes from large metal sheets without changing the circuit 
topology. 

> 

>This procesure has been applied to orchis and calliopel. Reticles for 
orchis 

>are now coming in but the tapes for the new version of calliopel are 
being 

>held until we see the resutls on orchis (which is acutally ahead of 

calliopel 

>in the fab) . 

> 

>There has been a great deal of discussion on the issue of going back 
>and def erf orating calliopeO, castor and pollux. It appears that we 
>will be 
doing 

>this now. Currently Hopper is checking to see what the resource 
situation 

>for doing this work is (we don't want to interfere with euterpe tapeout) . 
If 

>there is sufficient resources available we will do all three chips, if 
there 

>is a resource crunch it has been proposed to do only castor and pollux 
(castor 

>has only one cell that would need to be modified so it shouldn't take 

much 

>work) . 

Uhhh, it will take more work than previously thought. I ran a test over the weekend on 
castor/pollux. Castor generated a 400MB+ file and died because the scripts can't handle a 
file that size (I believe unix gives out at that point...) and pollux was over twice as 
big of an output file. 

I'm going to take a look at the two chips to see what cells will need changing since we 
can't deal with the chips in an 'as is' state. 


>The question we need to answer now is; are there any circuit blocks on 
>calliope0 that we need test results on that are not on pollux? If so 
>we will have to find the resources to fix calliope also. 
> 

>ln either case we will hold the tapes for calliopeO /castor/pollux until 
orchis 

>verifies the fix and we are reasonably sure that no additional changes 
are 

>needed. 
> 

>Please resond in the next couple of days if you believe that we need to 
update 
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>calliopeO . 
> 

>Paul 


I personally don't see any need for calliopeO, as calliopel will tell us even more than 
calliopeO will. Especially since euterpe tapeout will be starting soon. 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std_dis claim. h> 
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From: 
Sent: 
To: 

Subject: 


Tom Karzes [karzes@MicroUnity.com] 
Monday, October 17, 1994 5:13 PM 
'abbott@MicroUnity.com' 
assembler/simulator bug status 


> Look at -karzes/mysof t/stb/terp-src/stb/stand/diag/xlu. c for examples 

> of each of these errors . 
> 

> Let me know when you think these bugs are fixed and I'll rerun my tests. 

I just reran my short test and it looks like these bugs still aren't fixed. 
I don't think any work has been done on this since friday morning. It seems to me that 
correct simulation of the hardware in general, and of the XLU in particular , has to be 
about the highest priority software task we have since everything else is dependent on it. 
It also seems like a very simple task to me (at least as far as XLU simulation is 
concerned) . At this point it seems like the bugs are trivial and I really can't 
understand why they weren't fixed on friday, let alone by this afternoon. I also don't 
think we can honestly claim to have run any benchmark if it's being simulated on a machine 
which we don't plan to build. Just my opinion. . . 
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From: Tom Laidig [tom@clio] 

Sent: Monday, October 17, 1994 6:01 PM 

To: 'euterpe@clio' 

Cc: 'cadettes@clio'; Thomas Laidig' 

Subject: new leaf cells 


I've just released another leafmold bomb... er, BOM... which will do a complete rebuild of 
all leaf cell layouts. As before, I don't expect this to interfere with any gards work. 
The new features of this leaf cell set are: 

An improved use of the ripup router to handle some problems with it : 

It used to route over some primary I/O pins; an enhancement to 
gasavepins (thanks, Kurt!) fixes this 

Due to a bug in rroute, it routed some cells with high current 
paths daisy- chaining through metal- SDEC contacts; some vlsimm 
magic cleans this up 

The lobe layouts now get flattened into the leaf cells. Thus: 

If I tweak a lobe for some reason, the previously existing leaf 
cells don't immediately become bad 

It's easier to create an sc version of an xb cell this way; just 
copy it 

Dave doesn't have to keep the iss explode list current when new 
lobes are created 

They'll be lvs clean! Yes, even the xbcOl* cells! 

All but 16 cells are now routing to completion; about 1/3 as many as 
on my last try. 

I expect this build to run until sometime during the day tomorrow. Then I can rebuild the 
.pdl files . . . 


ooooO Ooooo 

( _) (_ > 
| ( Tom ) | 
(_) L (_) 
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From: Curtis Abbott [abbott@tallis] 

Sent: Monday, October 17, 1994 7:56 PM 

To: 'hardware@tallis'; 'software@tallis'; *staffers@tallis' 

Subject: MediaCom software presentation 


This Friday, Oct 21 at 2:00, there will be a presentation in the War Room about MediaCom 
software. We will try to summarize the way we're organizing the software, tell where we 
stand on a number of specific tasks that we've been working on, and draw out the lessons 
we think are important about using Euterpe to run DSP- intensive, real-time algorithms. 

- Curtis 
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Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 17, 1994 11:33 PM 


Subject: 


'Bruce Bateman' 
'geert@kephalos' 
M nemo/Euterpe 


Bruce Bateman wrote (on Mon Oct 17) : 

I've been working on a CMOS version of the Euterpe cache. Is 
this now on hold? Mail sounds like we're going to use the 
current Euterpe instead of a new CMOS version for the comparison. 

Sorry about missing 10am meeting - life conspired against me. 
Will be in tomorrow. 

P.S. - 1995 ISSCC will have the P6 , the new (62 0?) power- PC , 
the new DEC Alpha, and the HAL Sparc u-P. Should be quite 
a session. 

Comparison requires 2 implementations of Euterpe. Assumption is we have no choice but to 
use plain CMOS for the outside version. 

mouss has been saying that the spec /area performance of a MOBIMOS CMOS only version might 
be better than the performance of the BiCMOS version because area may go down faster than 
performance in switching to CMOS. Abolute performance is not the issue, only relative 
performance between an implementation on our process and the one on the outside process. 

The problem with this is that we then end up having to remap Euterpe twice not once. I 
resist that strongly, unless our analysis of the CMOS chip on the outside process suggests 
we cannot get a big enough advantage compared to the BiCMOS version. There is no point 
taking schedule risk going for more than we need. 

With regard to this morning's meeting, we were focussing there on the RAM we need in 
Mnemosyne. An issue is the power dissipation. We want 1Mbit + tag + ecc, which makes it 
about 1.5Mbit total. Bpw reconned we could do that easily with an array power of < 2W 
(very few writes) with a CMOS version derived from the old Mnemosyne design. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 17, 1994 11:43 PM 
'William Herndon' 

'bill@aphrodite'; Vo@aphrodite'; 'geert@aphrodite'; 'ong@aphrodite' 
Re: IO clock mismatch 


William Herndon wrote (on Mon Oct 17) : 


> From tbr@aphrodite Sun Oct 16 18:25:22 1994 

> Date: Sun, 16 Oct 1994 18:25:16 -0700 

> From: tbr@aphrod.it e (Tim B. Robinson) 

> To: bill@aphrodite 

> cc: vo@aphrodite , geert@aphrodite, ong@aphrodite 

> Subject: 10 clock mismatch 

> Content -Length: 753 


> There appear to be two reasons for the cycn problem with the I/O 

> clock. The clock is delivered lp from the mast. iobyte looks like it 

> wants a 2p clock, but in the top level the clock from the mast is sent 

> in directly as lp without any buffer. Second, the rate fifo which 

> also needs this clock buffers it with a number of sccgdr cells in 

> parallel. These expect Op input and produce 2p output. 
> 

> So, first we need to decide how to get from the lp signal from the 

> mast to the Op input to the sccgdr' s. Then if we have solved that, I 

> think we can add one more sccgdr to drive the 2p clock input to 

> iobyte. This should reduce the skew between the clock as seen by the 

> flops in iorate and those in iobyte. 
> 

> Please let me know what you recommend. 


I thought we wanted the flops in iobyte to occur before the clocks in iorate and this 
gave 

us more time on the path. As I recall, i don't think we needed the skew, it just helped 
things . 

In any case, we will have to look at the delay in detail once we get the circuitry 
right pwise. 

Your suggestion sounds good. We ought to make a lp sccgdr if we don't already have one 
and then 

take the output of the mast and drive something like 9 of these in parallel ( with 
less than 

1mm of wire on the input) and then get detailed loading of that path and analyze it. 
I still owe you the diagram showing how this hooks up. 

It is rather different from Calliope. On Calliope, the output clock was a buffered 
version of the input clock. On Euterpe, the output clock comes from the PLL and the input 
clock is used only in the input fifo section. The input section should be similar, with 
the flops in iobyte covering the delay of the parallel sccgdr 's. 

On the output side, we have to drive just 6 flops in iorate, plus the 
9 in iobyte. 


> 


> 


Tim 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 

Tuesday, October 18, 1994 12:30 AM 

'glen ©aphrodite'; 'rich ©aphrodite'; 'woody@aphrodite' 

'noel@aphrodite'; 'pmayer@aphrodite'; 'hestia@aphrodite' 

new parts 


According to noel at the electrical meeting this afternoon, we need some changes in the 
auxiliary VCO power supply because of the unavailability of the Murata converter. 

Action: glen to generate additional prt ' s as specified by noel 

Action: noel/rich to update schematic 

Action: woody prepare revised netlist for ECO 

More notes /actions to follow when I have my notes to hand. 


Tim 
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From: tbr 

Sent: Tuesday, October 1 8, 1 994 1 2:49 AM 

To: 'Mark Hofmann' 

Cc: 'Tom Vo' 

Subject: Re: Phase check results on Euterpe (fwd) 
Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Mon Oct 17): 

Tom Vo writes: 
Mark Hofmann wrote .... 
>Tom Vo writes: 

> Can't tell from this error because you're treat cgclockbias as one cell . 

> I think you need to expand down to the same level of csyn / celltest . 

> 

> ***Warning: At least one output [q__bm, net cerba2_am] of cerbu02u09u59 [xclatbc - phase unknown] 


> connects to an input [dSadOph] 

> of i o 1 infi foudoutuO [xbmuxfT6dh2 s - ph i__a2p] . 

> Instance iolinfifoudoutuO [xbmuxff6dh2s : flip-flop] driven by... 

> instance iolinfifoud5u0 [scioflf] driven by... 

> instance iolinfifoudmSuO [xbmux2dh3s] driven by... 

> instance iobytel [iobyte] driven by... 

> instance elk [cgclockbias] driven by... 

> instance cerbu00buf80a_l [ceinvx5] driven by... 

> instance cerbu00buf81a_l [ceinvx5] driven by... 

> instance cerbu00bufB2a_O [ceinvxS] driven by... 

> instance cerbuO 1 cga529 [ceinvxS] driven by... 

> instance cerbuO 1 cga3 291 [xcnand2c] driven by . . . 

> instance cerbuO lzz81 [xcinvc] driven by... 

> instance cerbuO lzz59 [xcnand4c] driven by... 

> instance cerbuO 1 zz3 9 [xcinvc] driven by . . . 

> instance cerbuO 1 zzl 8 [xcnand4c] driven by, . . 

> instance cerbu02u09u59 [xclatbc : latch]. 
> 


>Hmmm... The edif input that this was generated from treated cgclockbias 
>as a leaf cell- that is it called no other cells. Perhaps we could merge 
>in a more detailed model with emerge? What is the csyn/celltest level of 
>cgclockbias? 

> 

>-hopper 

Cgclockbias is a mix of cmos and eel circuits . For your purpose , it should 
not be considered a leaf cell . You need to expand downward until you hit 
a verilog property like csyn and celltest . 

tvo 

Hi Tim, 

I'm not familiar with the recipe, but it appears that we need an Edif 
netlist of Euterpe which would be suitable for csyn/celltest and LVS. I think 
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this means a call to emerge to expand the custom cells like cgclockbias, 
iobyte, etc. Could you generate a full chip Edif like that? Then I'll try 
another Gloss run. 

We need to copy something from the rule that makes the LVS netlist. 
I'm out of cycles to look at that now, but torn can probably cook up a 
rule easily. What I did was just take the output from topt. I'm not 
sure what we expect to find from looking inside cgclockbias though. 
Seems to em the opportunity for error is in the SOFA. 

Tim 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Tuesday, October 18, 1994 1:02 AM 
Vant' 

'Geert Rosseel'; "Mark Hofmann' 
tau checking? 


Follow Up Flag: Follow up 
Flag Status: Red 

vant wrote (on Mon Oct 1 7): 


Hi, I've been debugging an infinite loop in my TAU checking code and 
found that the TAU net goes to many things besides just TAU inputs (or 
the normal D input pins). For example, it appears to go to Select inputs 
for xbmuxff cells in the IQ section. 

Should topt 'stop' is check whenever it comes to a pin which is _not_ 
a D or D_N style input pin. What sort of rules should I be basing the 
check on. 

It is very close, to being done if I fix this problem. 

It does go to some mux selects. Till very recently there were some 
csyn errors there, because the normal tau buffer is an xbffe and we 
had to put in a regular flop to buffer the copy to the mux select. 

I don't think there is anything you can check in the case it goes to a 
select like that. It's an algorithmic thing that has to be checked 
dynamically in the simulator. The important cases are where it goes 
to the tau input on the hr cells. There we need the full check 
applied to the two hr cells at each end of a path. 


Tim 
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Subject 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Tuesday, October 18, 1994 1:02 AM 
'vant' 

'Geert RosseeP; 'Mark Hofmann' 
tau checking? 


vant wrote (on Mon Oct 17) : 


Hi, I've been debugging an infinite loop in my TAU checking code and 
found that the TAU net goes to many things besides just TAU inputs (or 
the normal D input pins) . For example, it appears to go to Select inputs 
for xbmuxff cells in the IQ section. 

Should topt 'stop' is check whenever it comes to a pin which is _not_ 
a D or D_N style input pin. What sort of rules should I be basing the 
check on. 

It is very close, to being done if I fix this problem. 

It does go to some mux selects. Till very recently there were some csyn errors there, 
because the normal tau buffer is an xbffe and we had to put in a regular flop to buffer 
the copy to the mux select . 

I don't think there is anything you can check in the case it goes to a select like that. 
It's an algorithmic thing that has to be checked dynamically in the simulator. The 
important cases are where it goes to the tau input on the hr cells. There we need the 
full check applied to the two hr cells at each end of a path. 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Tuesday, October 18, 1994 1:07 AM 

'geert'; 'torn' 

'woody' 

ice 


Follow Up Flag: Follow up 
Flag Status: Red 


A new section has been added in euterpe/verilog/bsrc/ to hold the 
icache control logic. I have made a symlink in /u/chip to point the 
gards dir at /s40 


Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Tuesday, October 1 8, 1 994 1 :07 AM 

To: 'geert@aphrodite'; , tom@aphrodite' 

Cc: 'woody@aphrodite' 

Subject: ice 


A new section has been added in euterpe/verilog/bsrc/ to hold the icache control logic. I 
have made a symlink in /u/chip to point the gards dir at /s4 0 

Tim 
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From: Mark Hofmann [hopper@tomato] 

Sent: Tuesday, October 1 8, 1 994 5:36 AM 

To: 'Tim B. Robinson 1 

Cc: Tom Vo'; 'Lisa Robinson' 

Subject: Re: Phase check results on Euterpe (fwd) 

Tim B. Robinson writes: 
Going from the LVS netlist would certainly be safer. It still exists 
in ~tbr/euterpe/veri 1 og/bsrc/tbr_euterpe-pas s 1 . sp 1 vs . 

However, as I understand it lisar is still waiting for a fix to spite. 
It may not affect the phase checking problem, but it does prevent us 
from running logic simulation, so we should be careful. 

Okay. Lisa will create an edif file and I'll try the Gloss run on that, 
-hopper 


Exhibit C7 


Page 328 of 703 


From: vant [vanthof@hestia] 

Sent: Tuesday, October 18, 1994 8:31 AM 

To: Tim B. Robinson' 

Cc: 'Geert Rosseel'; 'Mark Hofmann'; 'Dave Van't Hof 

Subject: Re: tau checking? 


Tim B. Robinson writes: 
> 

>It does go to some mux selects. Till very recently there were some 
>csyn errors there, because the normal tau buffer is an xbffe and we had 
>to put in a regular flop to buffer the copy to the mux select. 
> 

>I don't think there is anything you can check in the case it goes to a 
>select like that. It's an algorithmic thing that has to be checked 
>dynamically in the simulator. The important cases are where it goes to 
>the tau input on the hr cells. There we need the full check applied to 
>the two hr cells at each end of a path. 
> 

>Tim 


Okay, thanks. The problem I was running into was the algorithm I was using to set the 
phase for flops was by passing from input to output of gates until I got to a TAU input 
pin at which point I would stop. I'll change so that I stop at select pins as well. 

As far as actually checking the phase of the tau pins, I only check them on HR -> HR 
paths . 

Thanks , 
Dave 


Dave Van't Hof vant hof ©microunity . com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std_disclaim . h> 
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From: tbr 

Sent: Tuesday, October 1 8, 1 994 9:42 AM 

To: Vant' 

Cc: 'Geert RosseeP; 'Mark Hofmann' 

Subject: Re: tau checking? 
Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Tue Oct 1 8): 

Tim B. Robinson writes: 

> 

>It does go to some mux selects. Till very recently there were some 
>csyn errors there, because the normal tau buffer is an xbffe and we 
>had to put in a regular flop to buffer the copy to the mux select. 

> 

>I don't think there is anything you can check in the case it goes to a 
>select like that. It's an algorithmic thing that has to be checked 
dynamically in the simulator. The important cases are where it goes 
>to the tau input on the hr cells. There we need the full check 
>applied to the two hr cells at each end of a path. 
> 

>Tim 


Okay, thanks. The problem I was running into was the algorithm I was using 
to set the phase for flops was by passing from input to output of gates 
until I got to a TAU input pin at which point I would stop. I'll change 
so that I stop at select pins as well. 

As far as actually checking the phase of the tau pins, I only check them 
on HR -> HR paths. 

I think that's what we need. 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@nosferatu] 
Tuesday, October 18, 1994 9:42 AM 
'vant' 

'Geert RosseeP; 'Mark Hofmann' 
Re: tau checking? 


vant wrote (on Tue Oct 18) : 

Tim B. Robinson writes: 
> 

>lt does go to some mux selects. Till very recently there were some 
>csyn errors there, because the normal tau buffer is an xbffe and we 
>had to put in a regular flop to buffer the copy to the mux select. 
> 

>I don't think there is anything you can check in the case it goes to a 
>select like that. It's an algorithmic thing that has to be checked 
>dynaraically in the simulator. The important cases are where it goes 
>to the tau input on the hr cells. There we need the full check 
>applied to the two hr cells at each end of a path. 


Okay, thanks. The problem I was running into was the algorithm I was using 
to set the phase for flops was by passing from input to output of gates 
until I got to a TAU input pin at which point I would stop. I'll change 
so that I stop at select pins as well. 

As far as actually checking the phase of the tau pins, I only check them 
on HR -> HR paths. 

I think that's what we need. 


> 


>Tim 


Tim 
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From: Tom Laidig [tom@clio] 

Sent: Tuesday, October 18, 1994 1:15 PM 

To: Tim B. Robinson' 

Subject: Re: mnemo 

Tim B, Robinson writes: 
I 

|Can you go ahead and create a repository for this please? 

OK, so far, I've created the top-level directory and set up the layout 
stuff. I'll do the schematics area, and then call it good for the time 
being. In any case, you should be able to start creating verilog 
subtrees, and so forth. 

Right now, /u/chip/mnemo is sitting on slO along with the toplevel stuff 
of euterpe and some others. This may have to change, but I'm not sure 
how yet - we can move it later as desired. 

I set it up so the checkin log messages for 'mnemo' go to you, lisar, 
me, and the mnemosyne-checkins news group. Sound reasonable? 


Tom L 
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From: Tom Laidig [tom@c!io] 

Sent: Tuesday, October 1 8, 1 994 1 : 1 8 PM 

To: 'Tim B. Robinson 1 

Subject: Re: ice 

Tim B. Robinson writes: 
I 

| A new section has been added in euterpe/verilog/bsrc/ to hold the 
jicache control logic. I have made a symlink in /u/chip to point the 
jgards dir at /s40 

OK, good. 
Tom L 


Exhibit C7 


Page 333 of 703 


From: Tom Laidig [tom@dioj 

Sent: Tuesday, October 18, 1994 1:23 PM 

To: 'euterpe@clio' 

Cc: 'cadettes@clio'; Thomas Laidig' 

Subject: new leaf cell .pdls 

The build of leaf cell layouts completed successfully (well, all but the 
16 failures I expected). If there is no objection, I will fire off a 
rebuild of the .pdl files starting early this afternoon. This is 
another step that takes a long time (-10 hours?) but shouldn't impact 
ongoing gards activity, since each new .pdl file is moved into place 
atomically only after it's been successfully built. 


ooooO Ooooo 
(JO 
l( Tom )| 
C_J L (_J 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Tuesday, October 18, 1994 1:52 PM 

To: 'Mark Hofmann'; 'tom@nosferatu' 

Cc: Tim B. Robinson'; Tom Vo' 

Subject: Re: Phase check results on Euterpe (fwd) 


Mark Hofmann wrote (on Tue Oct 1 8): 

Tim B. Robinson writes: 
Going from the LVS netlist would certainly be safer. It still exists 
in ~tbr/euterpe/verilog/bsrc/tbr_euterpe-passl .spivs. 

However, as I understand it lisar is still waiting for a fix to spite. 
It may not affect the phase checking problem, but it does prevent us 
from running logic simulation, so we should be careful. 

Okay. Lisa will create an edif file and I'll try the Gloss run on that. 

-hopper 

The spite failed see /n/nosferatu/s2/euterpe/verilog/lvs 

Error (<stdin>.76385) — pin property is not on a subckt I/O pin 
gmake: *** [euterpe.edif3] Error 1 

and the last thing in the edif was 

(net (rename XB_AM„91_0_93_ "xb^am[0]") 
(joined 

( P ortRefXB_AM_91J)_93J 
(portRefXB_AM (instanceRef XI P_l )))))) 

Tom? 
Lisa R. 
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From: Tom Laidig [tom@clio] 

Sent: Tuesday, October 1 8 ( 1994 2:09 PM 

To: 'Lisa Robinson* 

Cc: 'hopper@tomato'; 'tom@nosferatu'; 'tbr@nosferatu'; Vo@tomato' 
Subject: Re: Phase check results on Euterpe (fwd) 

Lisa Robinson writes: 


|Mark Hofinann wrote (on Tue Oct 1 8): 
I Tim B. Robinson writes: 

j Going from the LVS netlist would certainly be safer. It still exists 
j i n ~tbr/euterpe/veri log/bsrc/tbr_euterpe-pas s 1 .spivs . 

j However, as I understand it lisar is still waiting for a fix to spite, 
j It may not affect the phase checking problem, but it does prevent us 
j from running logic simulation, so we should be careful. 

j Okay. Lisa will create an edif file and I'll try the Gloss run on that. 

j -hopper 

[The spite failed see /n/nosferatu/s2/euterpe/veri log/1 vs 

|Error (<stdin>.76385) - pin property is not on a subckt I/O pin 
jgmake: *** [euterpe.edifl] Error 1 

j and the last thing in the edif was 

(net (rename XB_AM_9 1_0_93_ "xb_am[0] ") 
(joined 

(portRefXB_AM_91_0_93J 
j (portRef XB_AM (instanceRef XI P_l )))))) 

|Tom? 

Ug. I'll take a look... 


Tom L 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Tuesday, October 18, 1994 2:56 PM 

Tom Laidig' 

'euterpe@clio'; 'cadettes@clio' 
Re: new leaf cell .pdls 


Tom Laidig writes : 

The build of leaf cell layouts completed successfully (well, all but 
the 

16 failures I expected) . If there is no objection, I will fire off a 
rebuild of the .pdl files starting early this afternoon. This is 
another step that takes a long time (-10 hours?) but shouldn't impact 
ongoing gards activity, since each new .pdl file is moved into place 
atomically only after it's been successfully built. 

Hearing no objections, I've started it. 


ooooO Ooooo 


( _) (_ ) 
| ( Tom ) | 
{_) L (_) 


Exhibit C7 


Page 337 of 703 


From: Jeff Marr [jeffm@kephalos] 

Sent: Tuesday, October 1 8, 1 994 3:49 PM 

To: 'euterpe@kephalos' 

Subject: Event Register Clears 


Is the following a feature, or a bug? 

If SW in a cylinder stores to the clear or set offset in the Euterpe event register, and 
then fetches the contents of the event register, there is a window where the load will see 
the old event register contents - the window is about 4 instructions wide. 

Comments? 


j ef fm 
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To: 


From: 
Sent: 


Lisa Robinson [lisar@nosferatu] 
Tuesday, October 18, 1994 6:16 PM 
'Brian Smith' 


Cc: Yich@nosferatu'; 'tbr@nosferatu' 
Subject: pll 

Brian Smith wrote (on Tue Oct 18): 

The pll verification is complete and released. 

I'm trying to run a simple hermes test but cannot seem to get anything 
out of pill. 

There is a verilog.dump on rhodan 

/s3/euterpe/verilog/bsrc/hermeseasy_0.dump and a ut on my screen. 


Lisa R. 
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From: Tom Laidig [tom@clio] 

Sent: Tuesday, October 18, 1994 6:34 PM 

To: 'Tom Laidig' 

Cc: 'lisar@nosferatu'; 'hopper@tomato'; 'tom@nosferatu'; 'tbr@nosferatu'; Vo@tomato' 
Subject: Re: Phase check results on Euterpe (fwd) 

Tom Laidig writes: 
I 

|Lisa Robinson writes: 


jjMark Hofmann wrote (on Tue Oct 18): 
II Tim B. Robinson writes: 

|| Going from the LVS netlist would certainly be safer. It still exists 
II in ~tbr/euterpe/veri log/bsrc/tbr_euterpe-pass 1 .sp 1 vs . 

|| However, as T understand it lisar is still waiting for a fix to spite. 
|| It may not affect the phase checking problem, but it does prevent us 
|| from running logic simulation, so we should be careful. 

j| Okay. Lisa will create an edif file and I'll try the Gloss run on that. 

|j -hopper 

||The spite failed see /n/nosferatu/s2/euterpe/verilog/lvs 

jjError (<stdin>, 76385) - pin property is not on a subckt I/O pin 
jjgmake: *** [euterpe.edifi] Error 1 

I |and the last thing in the edif was 

I I (net (rename XB__AM_9 1 _0_93_ "xb_am[0]") 
|| (joined 

I i (portRef XB_AM_9 1_0_93 J 

i ! (portRef XB AM (instanceRef X 1 P_l )))))) 

||Tom? 

jUg. I'll take a look... 

I'm not forgetting this... I thought at first that the message was 
properly complaining about something in the spice file as modified by 
peppermill (spite runs peppermill to filter out leaf cells and reformat 
the spice deck into define-before-use order; then pipes that into a C 
program), but this seems OK. I'm now trying to set it all up so I can 
run the C program in the debugger. This takes a while... 


Tom L 


Exhibit C7 


Page 340 of 703 


From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, October 18, 1994 8:31 PM 
'software-checkins-dist' 
gnu-tools/opcodes terp-opc.c 


Update of /p/cvsroot /gnu- tools /opcodes 

In directory calliope : /N/auspex/ root /s6/ lisa /src/gnu- tools/opcodes 

Modified Files: 

terp-opc . c 
Log Message: 

Changed egfmul64 from NOW to FUTURE. 
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From: tbr 

Sent: Tuesday, October 18, 1994 9:24 PM 

To: 'Bruce Bateman' 

Cc: , mouss@aphrodite'; 'al@aphrodite'; 'craig@aphrodite'; 'geert@aphrodite'; 'stick@aphrodite'; 

'bpw@aphrodite'; 'solo@aphrodite'; 'agc@aphrodite'; 'mnemo@aphrodite' 

Subject: Re: Mnemosyne redundancy 

Follow Up Flag: Follow up 

Flag Status: Red 


Bruce Bateman wrote (on Tue Oct 18): 


> Date: Mon, 17 Oct 1994 21:25:23 -0700 

> From: tbr@aphrodite (Tim B. Robinson) 

> To: mouss@aphrodite, al@apbrodite 

> cc: craig@aphrodite 1 geert@aphrodite, stick@aphrodite, bpw@aphrodite, 

> solo@aphrodite, agc@aphrodite, mnemo@aphrodite 

> Subject: Mnemosyne redundancy 


> We have been considering SRAM array structures for the new Mnemosyne. 

> A question which comes up immediately is how much, if any, redundancy 

> we should provide. 

> 

>...<snip>... 
> 

> How important an issue is this in MOBIMOS? Would we be willing to go 

> with no redundancy, or is some other scheme such as replacable 

> rows/colums adequate to deal with anticipated defect mechanisms? 

> 

>Tim 


When we were considering doing a lMeg SRAM for comercial sale (i.e. - 
Pentium cache) we had assumed that we would not use redundancy. The 
die size assumption was 0.52cm A 2 - 22u A 2 cell from euterpe and 45% 
efficiency. This die size is roughly 50% smaller than the 10mm X 10mm 
you project for mnemo, which would put the mnemo efficiency at 23% 
compared to the 35% you quoted for the roller-mnemo. Is something 
wrong with your 10X10 projection, or are you simply assuming the 
"standard" padring? 

We actually need about 1.5Mbits of actual RAM becuase of the overhead 
of cache tags and ECC. We are assuming a 10x10 die because that will 
minimise problems with changes to methodology, space transformers, TAB 
frames, assembly equipment etc. We are also very concerned to have 
plently of unused atoms inthe sofa so place and route is zero risk. 

Anyway, if we thought that we could do the other I Meg without 
redundancy, I don't see why we would want it for mnemo either. 
As to "schemes" for implementing the redundancy, there are plenty 
of ways of doing it with reasonable efficiency. The stickler for 
us is the programing element. Didn't the original mnemo require 
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some sort of initialization on power-up to implement the redundant 
block? This could be done on a "finer grain" - ie row/column 
redundancy by using ram cells to store the redundant address ala 
fpga's. There would be some overhead penalty for the greater 
flexability, but presumably not as bad as large scale block redundancy. 
The other disadvantage of this approach (compared to laser fuse 
redundancy) is the design in more complicated and there is the 
risk of some access time penalty. 

Input from Al is similar. Provided we stay with a 10x10 die, he sees 
no reason foer redundancy. I'd sooner leave it out because we can 
then go to an array structure with much higher efficiency. That in 
turn will ensure we are not pressed for space. 

The old scheme did require Cerberus programming and some form of in 
system test at initialization to determine bad block locations. 

Tim 
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From: 


tbr 


Subject: 


Sent: 


To: 


Tuesday, October 18, 1994 9:31 PM 
Tom Laidig' 
Re: mnemo 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Tue Oct 1 8): 

Tim B. Robinson writes: 

I 

|Can you go ahead and create a repository for this please? 

OK, so far, I've created the top-level directory and set up the layout 
stuff. I'll do the schematics area, and then call it good for the time 
being. In any case, you should be able to start creating verilog 
subtrees, and so forth. 

Right now, /u/chip/mnemo is sitting on slO along with the toplevel stuff 
of euterpe and some others. This may have to change, but I'm not sure 
how yet - we can move it later as desired. 

I set it up so the checkin log messages for 'mnemo' go to you, lisar, 
me, and the mnemosyne-checkins news group. Sound reasonable? 

Great. Thanks. 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Rich McCauley [rich@pegasus] 

Tuesday, October 18, 1994 9:51 PM 

'tbr@aphrodite* 

'hestia@pegasus' 

Re: Belated Netlist meeting notes 


> From tbr@aphrodite Tue Oct 18 19:17:39 1994 

> Date: Tue, 18 Oct 1994 19:17:24 -0700 

> From: tbr@aphrod±te (Tim B. Robinson) 

> To: hestia@aphrodite 

> cc: arya@aphrodite, pmayer@aphrodite , tbe@aphrodite , noel ©aphrodite , 

> woody@aphrodite, tbr@aphrodite 

> Subject: Belated Netlist meeting notes 

> Content -Length: 2785 


> We have a potential problem with the proposed ground plane 

> segmentation. This is because the RF component area has expanded to 

> cover an area that was previously Calliope digital ground. 

> Looks like we have three choices. 
> 

> a) We allow Calliope digital power planes under some RF areas {likely 

> would have to be one of the VCO's) . 
> 

> b) We take Calliope digital power under part of the SDRAM area. 
> 

> c) We use a common digital power plane for both Calliope and Euterpe 

> (which would also be under the SDRAM) . 

> 

> Action: We need inputs on which is the lesser of the above evils from 

> all interested parties. 
> 

If a) means having on of the VCOs share a leg of the ground plane with the digital chips, 
then I'm definitely not in favor of it, as I believe it will compromise the phase noise 
performance of the contingency VCOs. 


rich 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Tuesday, October 18, 1994 10:55 PM 

To: 'Mark Semmelmeyer' 

Cc: 'tbr@nosferatu'; 'doi@nosferatu' 

Subject: output of euterpe/verilog/bsrc/uu/.checkoutrc 

Mark Semmelmeyer wrote (on Tue Oct 18): 

I can't figure out why uusteput.pla is not getting copied 
into /u/chip when I release uu. Without it, the build 
fails, help! 

Mark it looks like you need to cvs add it. 
Lisa R. 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Tuesday, October 18, 1994 10:59 PM 

To: 'geert@nosferatu'; 'hopper@nosferatu'; 'solo@nosferatu' 

Cc: 'tbr@nosferatu'; Vo@nosferatu'; Vant@nosferatu'; 'tom@nosferatu'; 'brianl@nosferatu'; 

'doi@nosferatu' 

Subject: forwarded message from Charlie Root 


Does any one know what this is? I have lots of them! 
Lisa R. 


Start of forwarded message 

Status: RO 

X-VM-v5-Data: ( [nil nil nil nil nil nil nil nil nil] 

["3938" "Tue" "18" "October" "1994" "20:31: 00" "-0700" "Charlie Root" " root ©cyclops 
» nil "107" "Output from V'atV job" ,,x From:" nil nil 
"10"] ) 

Return- Path: <root@cyclops> 

Received: from cyclops.microunity.com by gaea.microunity.com (4 . 1/musel . 3 ) 

id AA24212; Tue, 18 Oct 94 20:31:00 PDT 
Received: from localhost by cyclops.microunity.com (8 . 6 . 4/muse-sw. 2 ) 

id UAA26654; Tue, 18 Oct 1994 20:31:00 -0700 
Message- Id: <199410190331 .UAA2 6654@cyclops .microunity .com> 
From: root@cyclops (Charlie Root) 
To: lisar@cyclops 
Subject: Output from "at" job 
Date: Tue, 18 Oct 1994 20:31:00 -0700 

Your "at" job "1993" produced the following output: 


Warning! The CHIPR00T environment is not set. Will set to /u/chip 


Working cell : hrlatlx2 
Using flow: 

/n/auspex/s41/euterpe-proteus/proteus/technology/mobimos/iss//mobilpel .met 
. vc 

Translation table for Cif To Stream: 

/n/auspex/s41/euterpe-proteus/proteus/tools/lib/stream/mobimosl . tbl 

Current working directory: /usr/local/etc/dracjobs/isslpe Current Layout: hrlatlx2 
rm : cannot remove * . ' or * . . 1 
rm : cannot remove * . ' or * . . 1 

LTLPATH: /a/iss 

ISSPATH: /a/iss 

ISS_SYSTYPE : SUN4 

ISS_LSERVER: hestia 

/a/ iss/SUN4__verichk/vc engine 

/**************** **********************************^ 

* * 

* IIIIIII SSSSSS SSSSSS * 

* I S S * 

* IS s * 

* I sssss sssss * 

* I s s * 

* I s s * 

* IIIIIII SSSSSS SSSSSS * 
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/********************************************************************/ 


Creating composite LPE explode and flatten lists 
Starting date: Tue Oct 18 20:30:28 PDT 1994 
/u/chip/tools/bin/cif les -c hrlatlx2 -v 

/n/auspex/s41/euterpe-proteus/proteus/lpe/lobes/vlsi .boo -o 26544. cif -h cell . equiv -I -n 
26544.txt -e 1 -Y -G BBOX -s 0.05 >>& hrlatlx2.log /u/chip/tools/bin/cif tostrm -I 
26544. cif -O datain.dat -X /n/auspex/s4l/euterpe- 

proteus/proteus/tools/lib/stream/mobimosl . tbl -h Translation of 26544. cif succeeded. 
Root symbol is called ROOTCELL. 
Running veri check 

gdsin: 5.1.2 6/22/94 

gdsout: 5.1.8 6/6/94 

here: 2.4.2 7/21/94 

lsh: 2.4.15 8/18/94 

vc_engine: 2.4.12 2 8/30/94 

vp: 2.4.17 7/11/94 
VeriCheck is done. 

VeriCheck (R) Hierarchical Design Verification, BETA 2.4.1 
<C) Copyright 1990, 1991, 1992, 1993, 1994. 
Integrated Silicon Systems, Inc. All rights reserved. 
This product contains confidential information and trade secrets of 
Integrated Silicon Systems, Inc. Any use or disclosure, except as 
authorized in writing by Integrated Silicon Systems, Inc., is 
prohibited. Copyright is claimed in this product as an unpublished 
work, and the copyright notice does not imply publication. 

Printing individual version numbers ... 

vericheck: 2.4.9 8/24/94 

VERICHECK WARNING : At or near line 3 99: 

TEMP layer "notmet23ped" defined but never used 

VERICHECK WARNING : At or near line 3 98: 

TEMP layer "notmet34ped" defined but never used 

VERICHECK WARNING : At or near line 412: 

TEMP layer "n+gateab" defined but never used 

VERICHECK WARNING : At or near line 411: 

TEMP layer "n+gateup" defined but never used 

VERICHECK WARNING : At or near line 400: 

TEMP layer "gatepoly" defined but never used 

VERICHECK WARNING : At or near line 410: 

TEMP layer "p+gateab" defined but never used 

VERICHECK WARNING : At or near line 4 09: 

TEMP layer "p+gateup" defined but never used 

VeriCheck is done . 

******************************************* 
* Compare summary * 

grep: HRLAT1X2 . cmpsum : No such file or directory 
grep: HRLAT1X2 . cmpsum : No such file or directory 
******************************************* 


******************************************* 
******************************************* 
** * * 

** THERE ARE OPENS IN YOUR CIRCUIT ** 
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** PLEASE LOOK IN HRLAT1X2 . err 

** ** 

******************************************* 

******************************************* 


cat hrlatlx2.log >> 

/n/auspex/s4l/euterpe-proteus/proteus/lpe/lobes/hrlatlx2 . compare_lpe/hrlat 
1x2 . lpelog 

ISS LPE completed 

En a C f forwarded message 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Tuesday, October 18, 1994 11:24 PM 
'Jeff Man*' 

'euterpe@kephalos' 
Event Register Clears 


Jeff Marr wrote (on Tue Oct 18) : 

Is the following a feature, or a bug? 

If SW in a cylinder stores to the clear or set offset in the Euterpe event register, 
and then fetches the contents of the event register, there is a window where the 
load will see the old event register contents - the window is about 4 instructions 
wide. 

It ' s a bug. The normal store/ load interlock ought to catch it. 


Tim 
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From: Mark Semmelmeyer [mws@clytemnestra] 

Sent: Tuesday, October 1 8, 1 994 11 :33 PM 

To: 'jeffm@kephalos'; 'tbr@aphrodite' 

Cc: 'euterpe@kephalos' 

Subject: Re: Event Register Clears 


> From tbr@aphrodite Tue Oct 18 21:24:34 1994 
> 

> Jeff Marr wrote (on Tue Oct 18) : 
> 

> is the following a feature, or a bug? 
> 

> If SW in a cylinder stores to the clear or set offset in the 

> Euterpe 
event register, 

> and then fetches the contents of the event register, there is a 
window where the 

> load will see the old event register contents - the window is about 

> 4 

instructions 

> wide . 
> 

> It's a bug. The normal store/ load interlock ought to catch it. 
> 

> Tim 

These are different addresses, and unless we widen the hazard match considerably, they are 
not automatically caught. 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Tuesday, October 18, 1994 11:37 PM 

To: 'Mark Semmelmeyer' 

Cc: 'doi@nosferatu'; 'tbr@nosferatu' 

Subject: Re: output of euterpe/verilog/bsrc/uu/.checkoutrc 


Mark Semmelmeyer wrote (on Tue Oct 1 8): 


> From lisar@nosferatu Tue Oct 18 20:55:09 1994 

> Date: Tue, 18 Oct 1994 20:55:07 -0700 

> From: Iisar@nosferatu (Lisa Robinson) 

> To: mws@clytemnestra (Mark Semmelmeyer) 

> Subject: output of euterpe/verilog/bsrc/uu/.checkoutrc 

> Cc: tbr@nosferatu, doi@nosferatu 

> Content-Length: 231 
> 

> 

> Mark Semmelmeyer wrote (on Tue Oct 18): 

> 

> 1 can't figure out why uusteput.pla is not getting copied 

> into /u/chip when I release uu. Without it, the build 

> fails, help! 

> 

> Mark it looks like you need to cvs add it. 

> 

> Lisa R. 

> 

try a cvs status on it and its there 


Iisar@rhodan /s3/euterpe/veriIog/bsrc/uu 403 % cvs status uusteput.pla 
cvs status: nothing known about uusteput.pla 


File: no file uusteput.pla Status: Unknown 

Version: No entry for uusteput.pla 
RCS Version: No revision control file 

lisar@rhodan /s3/euterpe/verilog/bsrc/uu 404 % pushd /u/chip/euterpe/verilog/bsrc/u 
u 

lisar@rhodan /u/chip/euterpe/verilog/bsrc/u u 405 % cvs status uusteput.pla 
cvs status: nothing known about uusteput.pla 


File: no file uusteput.pla Status: Unknown 

Version: No entry for uusteput.pla 

RCS Version: No revision control file 

In your area it says: 


lisar@rhodan /n/auspex/s24/mws/euterpe/verilog/bsrc/uu 407 % cvs status uusteput.pl 
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cvs status: uusteput.pla is no longer in the repository 


File: uusteput.pla Status: Entry Invalid 

Version: 84.2 Tue Oct 1 8 20: 12:33 1 994 

RCS Version: No revision control file 
Sticky Tag: (none) 
Sticky Date: (none) 
Sticky Options: (none) 

Uhmm it is not in the Attic though. 

I'll call doi. 

Lisa R. 


Exhibit C7 


Page 353 of 703 


From: Lisa Robinson [lisar@nosferatu] 
Sent: Tuesday, October 1 8, 1 994 1 1 :48 PM 
To: 'Mark Semmelmeyer' 

Cc: 'mws@nosferatu'; 'doi@nosferatu'; 'tbr@nosferatu' 
Subject: Re: output of euterpe/verilog/bsrc/uu/.checkoutrc 


Mark the file in the repository is read only by you. So mortals like 
me and chip cannot read it. 

Change the premissons on it and check the group and then it should 
work. 

2-r Imws 1355 Oct 18 20:12 uusteput.pla,v 


Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 

Wednesday, October 19, 1994 12:01 AM 

'Rich McCauley' 

'hestia@pegasus' 

Re: Belated Netlist meeting notes 


Rich McCauley wrote (on Tue Oct 18) : 


> From tbr@aphrodite Tue Oct 18 19:17:39 1994 

> Date: Tue, 18 Oct 1994 19:17:24 -0700 

> From: tbr@aphrodite (Tim B. Robinson) 

> To: hestia@aphrodite 

> cc: arya@aphrodite, pmayer@aphrodite, tbe@aphrodite, noel@aphrodite, 

> woody@aphrodite, tbr@aphrodite 

> Subject: Belated Netlist meeting notes 

> Content -Length: 27 85 


> We have a potential problem with the proposed ground plane 

> segmentation. This is because the RF component area has expanded to 

> cover an area that was previously Calliope digital ground. 

> Looks like we have three choices. 
> 

> a) We allow Calliope digital power planes under some RF areas (likely 

> would have to be one of the VCO's) . 
> 

> b) We take Calliope digital power under part of the SDRAM area. 
> 

> c) We use a common digital power plane for both Calliope and Euterpe 

> (which would also be under the SDRAM) . 
> 

> Action: We need inputs on which is the lesser of the above evils from 

> all interested parties. 
> 

If a) means having on of the VCOs share a leg of the ground plane with the 
digital chips, then I'm definitely not in favor of it, as I believe it will 
compromise the phase noise performance of the contingency VCOs. 

It would be sharing it with Calliope. Euterpe and the DRAM would be on a separate plane 
under this option. 


Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Wednesday, October 19, 1994 12:23 AM 

To: 'Mark Semmelmeyer' 

Cc: 'jeffm@kephalos\ 'euterpe@kephalos' 

Subject: Re: Event Register Clears 


Mark Semmelmeyer wrote (on Tue Oct 18) : 


> From tbr@aphrodite Tue Oct 18 21:24:34 1994 
> 

> Jeff Marr wrote (on Tue Oct 18) : 

> Is the following a feature, or a bug? 
> 

> If SW in a cylinder stores to the clear or set offset in the 
Euterpe event register, 

> and then fetches the contents of the event register, there is a 
window where the 

> load will see the old event register contents - the window is 
about 4 instructions 

> wide . 
> 

> it's a bug. The normal store/load interlock ought to catch it. 
> 

> Tim 

These are different addresses, and unless we widen the hazard match 
considerably, they are not automatically caught. 

Oops sorry, I did not read the original message properly. So is it the case that we are 
(correctly catching the case of store/load to the "normal" address? I agree it would be 
an unsightly kludge to have to add in something special to detect this alias. I would 
propose we don't do so unless there is some overriding software reason why it introduces 
an impossible to handle hazard. I guess it's a consequence of using address bits instead 
of opcode bits. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Wednesday, October 19, 1994 9:13 AM 

Tom Laidig' 

'euterpe@clio'; 'cadettes@clio' 
Re: new leaf cell .pdls 


Tom Laidig writes: 

Tom Laidig writes: 

The build of leaf cell layouts completed successfully (well, all but 
the 

16 failures I expected) . If there is no objection, I will fire off a 
rebuild of the .pdl files starting early this afternoon. This is 
another step that takes a long time (-10 hours?) but shouldn't impact 
ongoing gards activity, since each new .pdl file is moved into place 
atomically only after it's been successfully built. 

Hearing no objections, I've started it. 

And it 1 s done . 


ooooO Ooooo 


| ( Tom ) | 
(_) L (_) 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Paul Poenisch [paulp@acteon] 
Wednesday, October 19, 1994 10:00 AM 
'euterpe@acteon' 
'Albert Matthews' 
tape out scheduling 


Hi, 


In reading the ongoing messages about the preparation of euterpe for tape out I get the 
impression that the base layers will be ready for sending tapes to the mask shop on or 
about November 1 while the metal layers will be one or two week (more?) latter. Please be 
advised that the mask shops object fairly strongly to this type of scheduling. 

We are currently ordering reticles in complete sets (ie 010 through 280 or 510 through 
560) . Sending the tapes to the shop in two (or more) separate batches causes serious 
scheduling problems for them as they typically have to set up their process for our 
reticles twice (our reticles probably don't run through on a standard production basis) . 
Additionally if we can not give them firm dates for the arrival of the second batch of 
tapes scheduling of our work vs. 

other customer's work becomes a serious issue (guess who looses). 

Currently I believe that we have only one qualified mask vendor (that we expect can 
deliver reticles when they say they can) . We have been getting good service from them by 
throwing large sums of money at them, otherwise our work doesn't move very fast. Giving 
them tapes in multiple batches for the same device with uncertain delivery dates is going 
to extend the period of time we will need to give them large insentives to do our work, 
resulting in us spending a lot more money on reticle than we might otherwise. 

Even though we might be able to save a few days between initial tape out and first silicon 
on a device by splitting up the tape out, I think in the long run we will be better off by 
sending all the tapes at once. This will make the mask shops happier to see our tapes 
without $10,000 bills attached to them and will not cost us much time (retical 
manufacturing will likely be a bottle neck so we will always be waiting for that last 
reticle to come in no mater how we try to get the first tapes to them early) . 

Please keep this in mind when planning future tapeouts. 


Paul. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Wednesday, October 19, 1994 10:35 AM 
'Paul Poenisch' 

'al@nosferatu'; 'euterpe@nosferatu' 
tape out scheduling 


Paul Poenisch wrote (on Wed Oct 19) : 


Hi, 


In reading the ongoing messages about the preparation of euterpe for tape out 
I get the impression that the base layers will be ready for sending tapes to 
the mask shop on or about November 1 while the metal layers will be one or 
two week (more?) latter. Please be advised that the mask shops object fairly 
strongly to this type of scheduling. 

We are currently ordering reticles in complete sets (ie 010 through 2 80 or 510 
through 560) . Sending the tapes to the shop in two (or more) separate batches 
causes serious scheduling problems for them as they typically have to set up 
their process for our reticles twice (our reticles probably don't run through 
on a standard production basis) . Additionally if we can not give them firm 
dates for the arrival of the second batch of tapes scheduling of our work vs. 
other customer's work becomes a serious issue (guess who looses). 

Paul since there are 3 0 or so masks and the mask vendors are only processing at best about 
1 a day (correct me if this has changed) , passing all of the tapes to them at once forces 
a perhaps unnecessary serialization. Within the industry concurrent engineering is 
becoming the norm and given our methodology it seems "natural" to deliver the tapes in 2 
lots. Indeed when there are metal fixes, only the second lot would be shipped. 

I agree, however that you do need to be able to schedule the second lot with the vendor 
and that we should be providing our best estimate of that date. 


Currently I believe that we have only one qualified mask vendor (that we expect 
can deliver reticles when they say they can) . We have been getting good 
service from them by throwing large sums of money at them, otherwise our work 
doesn't move very fast. Giving them tapes in multiple batches for the same 
device with uncertain delivery dates is going to extend the period of time 
we will need to give them large insentives to do our work, resulting in us 
spending a lot more money on reticle than we might otherwise. 

Even though we might be able to save a few days between initial tape out and 
first silicon on a device by splitting up the tape out, I think in the long 
run we will be better off by sending all the tapes at once. This will make the 
mask shops happier to see our tapes without $10,000 bills attached to them and 
will not cost us much time (retical manufacturing will likely be a bottle neck 
so we will always be waiting for that last reticle to come in no mater how we 
try to get the first tapes to them early) . 

Please keep this in mind when planning future tapeouts. 


Lisa R. 


Paul . 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 

Wednesday, October 19, 1994 11:04 AM 

'agc@aphrodite' 

, geert@aphrodite' 

io 


Please take a look at the route of I/O since I put in the timing fix lat night. he 
completed OK, io died with exit 1 which I think must mean one instance worked and the 
other failed. Are the placements different? I only updated one. 


The output from euterpe/verilog/bsrc/io/ . checkoutrc is 240k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/tbr .gamorra . 23 624 . euterpe-verilog-bsrc-io 

(which is accessible from all machines). This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 1. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Paul Poenisch [paulp@acteon] 
Wednesday, October 19, 1994 11:09 AM 
'Lisa Robinson' 

'Albert Matthews'; 'euterpe@acteon' 
Re: tape out scheduling 


Lisa R. writes: 
> 

> Paul since there are 3 0 or so masks and the mask vendors are only 

> processing at best about 1 a day (correct me if this has changed) , 

> passing all of the tapes to them at once forces a perhaps unnecessary 

> serialization. Within the industry concurrent engineering is becoming 

> the norm and given our methodology it seems "natural" to deliver the 

> tapes in 2 lots. Indeed when there are metal fixes, only the second 

> lot would be shipped. 
> 

> I agree, however that you do need to be able to schedule the second 

> lot with the vendor and that we should be providing our best estimate 

> of that date. 


I agree that given our methodology delivering the tapes in 2 lots is natural, my previous 
employer (LSI Logic) did it all the time for exactly the same reason. However the reticle 
making process is in fact serial, the vendor gernerally has only 1 (or at most 2) e-beam 
systems and usually only 1 inspection system suitable for our reticles and the reticles go 
through these systems one at a time . 

Because our reticles are more difficult that the average reticle the shops do, they will 
typically tweek the process for our jobs. Splitting the tapes into two batches means that 
the vendor usually has to set up for us, process our first batch, set up for other jobs, 
process them then set up for our second batch. This causes delays in our second batch 
(the one that will determine when we actually get silicon out) because we have to wait for 
someone else's job to finish and it take significant time (1 or 2 days?) to re-set up for 
our reticles. 

I suspect that we will find in the long run we gain very little time in sending out a tape 
set in 2 batches and end up irritating our vendor into not wanting to do business with us. 

As for metal sets only, we would send them to the vendor all at once and that's all they 
would expect so that shouldn't cause a problem. The difficulty is when we order a full 
set but only send a partial set of tapes. 


> 


> Lisa R. 


> 


Paul . 
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From: tbr 

Sent: Wednesday, October 19, 1994 1 1:19 AM 

To: 'Paul Poenisch' 

Cc: 'euterpe@acteon'; 'Albert Matthews' 

Subject: tape out scheduling 


Follow Up Flag: Follow up 
Flag Status: Red 


Paul Poenisch wrote (on Wed Oct 19): 
Hi, 

In reading the ongoing messages about the preparation of euterpe for tape out 
I get the impression that the base layers will be ready for sending tapes to 
the mask shop on or about November 1 while the metal layers will be one or 
two week (more?) latter. Please be advised that the mask shops object fairly 
strongly to this type of scheduling. 

We intend to have tapes written for the base layers by Nov 1 . It is 
up to the fab to schedule mask generation. The metal layers will be 
at least 2 weeks later. At this point we still have substantial work 
to do in the SOFA to get the logic completed, debugged, routed and to 
make timine. 

We are currently ordering reticles in complete sets (ie 010 through 280 or 510 
through 560). Sending the tapes to the shop in two (or more) separate batches 
causes serious scheduling problems for them as they typically have to set up 
their process for our reticles twice (our reticles probably don't run through 
on a standard production basis). Additionally if we can not give them firm 
dates for the arrival of the second batch of tapes scheduling of our work vs. 
other customer's work becomes a serious issue (guess who looses). 

Understood. However, it is part of our plan that, process problems 
asside, we will debug the chips by changing metal layers only, so we 
should definitely have the mask shops expecting jobs equivalent to 
only the second half. 

Currently I believe that we have only one qualified mask vendor (that we expect 
can deliver reticles when they say they can). We have been getting good 
service from them by throwing large sums of money at them, otherwise our work 
doesn't move very fast. Giving them tapes in multiple batches for the same 
device with uncertain delivery dates is going to extend the period of time 
we will need to give them large insentives to do our work, resulting in us 
spending a lot more money on reticle than we might otherwise. 

Conversly, delaying the start of mask generation when we know the best 
we can expect is one mask per day will add at least 10 days to the 
schedule. Per mouss's equation, that can be seen to cost $800K. I 
see the problem arising if we start the first set without the 
reasonable expectation that the remaining tapes will be delivered 
inside that 10 day window. 

Even though we might be able to save a few days between initial tape out and 
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first silicon on a device by splitting up the tape out, I think in the long 
run we will be better off by sending alt the tapes at once. This will make the 
mask shops happier to see our tapes without $10,000 bills attached to them and 
will not cost us much time (retical manufacturing will likely be a bottle neck 
so we will always be waiting for that last reticle to come in no mater how we 
try to get the first tapes to them early). 

Please keep this in mind when planning future tapeouts. 

>From our side it is very important to be able to partition the tapeout 
process and get the diffusion layers clean and out of our hair. If 
the tapes sit on the shelf while we finish the job, in odrder to get 
better service from the mask shop, that's fine with me and for the fab 
to call I think. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, October 19, 1994 11:19 AM 
'Paul Poenisch' 

'euterpe@acteon'; 'Albert Matthews' 
tape out scheduling 


Paul Poenisch wrote (on Wed Oct 19) : 


Hi, 


In reading the ongoing messages about the preparation of euterpe for tape out 
I get the impression that the base layers will be ready for sending tapes to 
the mask shop on or about November 1 while the metal layers will be one or 
two week (more?) latter. Please be advised that the mask shops object fairly 
strongly to this type of scheduling. 

We intend to have tapes written for the base layers by Nov 1 . It is up to the fab to 

schedule mask generation. The metal layers will be at least 2 weeks later. At this point 

we still have substantial work to do in the SOFA to get the logic completed, debugged, 
routed and to make timine. 

We are currently ordering reticles in complete sets (ie 010 through 2 80 or 510 
through 560) . Sending the tapes to the shop in two (or more) separate batches 
causes serious scheduling problems for them as they typically have to set up 
their process for our reticles twice (our reticles probably don't run through 
on a standard production basis) . Additionally if we can not give them firm 
dates for the arrival of the second batch of tapes scheduling of our work vs. 
other customer's work becomes a serious issue (guess who looses). 

Understood. However, it is part of our plan that, process problems asside, we will debug 
the chips by changing metal layers only, so we should definitely have the mask shops 
expecting jobs equivalent to only the second half. 

Currently I believe that we have only one qualified mask vendor (that we expect 
can deliver reticles when they say they can) . We have been getting good 
service from them by throwing large sums of money at them, otherwise our work 
doesn't move very fast. Giving them tapes in multiple batches for the same 
device with uncertain delivery dates is going to extend the period of time 
we will need to give them large insentives to do our work, resulting in us 
spending a lot more money on reticle than we might otherwise. 

Conversly, delaying the start of mask generation when we know the best we can expect is 
one mask per day will add at least 10 days to the schedule. Per mouss ' s equation, that 
can be seen to cost $800K. I see the problem arising if we start the first set without 
the reasonable expectation that the remaining tapes will be delivered inside that 10 day 
window . 

Even though we might be able to save a few days between initial tape out and 
first silicon on a device by splitting up the tape out, I think in the long 
run we will be better off by sending all the tapes at once. This will make the 
mask shops happier to see our tapes without $10,000 bills attached to them and 
will not cost us much time (retical manufacturing will likely be a bottle neck 
so we will always be waiting for that last reticle to come in no mater how we 
try to get the first tapes to them early) . 

Please keep this in mind when planning future tapeouts. 

>From our side it is very important to be able to partition the tapeout 

process and get the diffusion layers clean and out of our hair. If the tapes sit on the 
shelf while we finish the job, in odrder to get better service from the mask shop, that's 
fine with me and for the fab to call I think. 


Tim 
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From: Wayne Freitas [wayne@mercury] 
Sent: Wednesday, October 19, 1994 1 1:30 AM 
To: 'tbr@aphrodite' 
Subject: Re: Belated Netlist meeting notes 


> 

> The question was asked if we can completely shut off the second Hermes 

> channel when nothing is plugged to the expansion port to avoid a 

> potential EMI problem, tbr thinks yes, but needs to check. Issue is 

> whether knob controls allow output current to be set to 0. The 

> logical "Channel Disable" is not enough because it causes idle packets 

> to be transmitted continuously. 
> 

> Action: tbr to confirm we can shut this off completely. 

> 
> 

Tim, excuse me if I ask a dumb question, but being that Euterpe actually 
has two Hermes channels, I would think that they would be independent. 
If this is the case wouldn't you have either seperate enables and idle 
pattern registers. Sorry I don't have a copy of the Euterpe Micro-arch itechure 
document 


Wayne 
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From: craig 

Sent: Wednesday, October 1 9, 1 994 1 1 :39 AM 

To: , mws@clytemnestra , ; 'tbr@aphrodite' 

Cc: 'euterpe@kephalos'; , jeffm@(<ephalos , 

Subject: Re: Event Register Clears 

By using strong ordering, the hazard is eliminated. 
Craig 
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From: tbr 

Sent: Wednesday, October 1 9, 1 994 1 1 :40 AM 

To: 'Wayne Freitas' 

Cc: 'bill'; 'ong' 

Subject: Re: Belated Netlist meeting notes 

Follow Up Flag: Follow up 

Flag Status: Red 


Wayne Freitas wrote (on Wed Oct 1 9): 


> 

> The question was asked if we can completely shut off the second Hermes 

> channel when nothing is plugged to the expansion port to avoid a 

> potential EMI problem, tbr thinks yes, but needs to check. Issue is 

> whether knob controls allow output current to be set to 0. The 

> logical "Channel Disable" is not enough because it causes idle packets 

> to be transmitted continuously. 
> 

> Action: tbr to confirm we can shut this off completely. 

> 
> 

Tim, excuse me if I ask a dumb question, but being that Euterpe actually 
has two Hermes channels, I would think that they would be independent. 
If this is the case wouldn't you have either seperate enables and idle 
pattern registers. Sorry I don't have a copy of the Euterpe Micro-architechure 
document 


The share a common idle patern since that is built into the protocol. 
They have separate channel disable bits (Cerberus controlled), but the 
definition of disabled in that sense is the that the output sends out 
idles and the input is ignored. What we need here is an electrical 
disable so we are not toggling the data lines constantly. 

Bill, warren, do you know if we can set the output current to 0 for 
sure? 


Tim 


Exhibit C7 


Page 367 of 703 


From: Buffalo Chip [chip@rhea] 

Sent: Wednesday, October 19, 1994 1 1:43 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/io BOM 23.0 initiated by age completed @ Wed Oct 19 09:41:30 
PDT 19 94 with exit status 2.. chip 
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From: William Herndon [biII@polyhymnia] 

Sent: Wednesday, October 19, 1 994 1 1 :56 AM 

To: l mouss@aphrodite'; 'al@aphrodite'; 'tbr@aphrodite'; , stick@kephaios' 

Cc: 'craig@aphrodite'; 'geert@aphrodite*; 'stjck@aphrodite'; 'bpw@aphrodite'; 'solo@aphrodite'; 

'agc@aphrodite'; 'm nemo @aph rod ite' 
Subject: Re: Mnemosyne redundancy 


> From stick@kephalos Tue Oct 18 09:56:19 1994 

> Date: Tue, 18 Oct 1994 09:56:02 -0700 

> From: stick@kephalos (Bruce Bateman) 

> To: mouss@aphrodite, al@aphrodite, tbr@aphrodite 

> Subj ect : Re ; Mnemosyne redundancy 

> Cc: craig@aphrodite, geert@aphrodite, stick@aphrodite, bpw@aphrodite, 

> solo@aphrodite, agcOaphrodite, mnemo@aphrodite 

> Content -Length: 2 005 
> 

> > Date: Mon, 17 Oct 1994 21:25:23 -0700 

> > From: tbrOaphrodite (Tim B. Robinson) 

> > To: mouss@aphrodite, al@aphrodite 

> > cc: craig@aphrodite, geert@aphrodite, stick@aphrodite, bpw@aphrodite, 

> > solo@aphrodite, agc@aphrodite , mnemo@aphrodite 

> > Subject: Mnemosyne redundancy 

> > 

> > 

> > We have been considering SRAM array structures for the new Mnemosyne. 

> > A question which comes up immediately is how much, if any, 

> > redundancy we should provide. 
-> > 

> > . . . <snip> . . . 

> > 

> > How important an issue is this in MOBIMOS? Would we be willing to 

> > go with no redundancy, or is some other scheme such as replacable 

> > rows/colums adequate to deal with anticipated defect mechanisms? 

> > 

> > Tim 

> > 

> > 
> 

> When we were considering doing a lMeg SRAM for comercial sale (i.e. - 

> pentium cache) we had assumed that we would not use redundancy. The 

> die size assumption was 0.52cm A 2 - 22u A 2 cell from euterpe and 45% 

> efficiency. This die size is roughly 5 0% smaller than the 10mm X 10mm 

> you project for mnemo, which would put the mnemo efficiency at 23% 

> compared to the 35% you quoted for the roller-mnemo . Is something 

> wrong with your 10X10 projection, or are you simply assuming the 

> "standard" padring? 
> 

> Anyway, if we thought that we could do the other lMeg without 

> redundancy, I don't see why we would want it for mnemo either. 

> As to "schemes" for implementing the redundancy, there are plenty of 

> ways of doing it with reasonable efficiency. The stickler for us is 

> the programing element. Didn't the original mnemo require some sort 

> of initialization on power -up to implement the redundant block? This 

> could be done on a "finer grain" - ie row/ column redundancy by using 

> ram cells to store the redundant address ala fpga's. There would be 

> some overhead penalty for the greater flexability, but presumably not 

> as bad as large scale block redundancy. 

> The other disadvantage of this approach (compared to laser fuse 

> redundancy) is the design in more complicated and there is the risk of 

> some access time penalty. 
> 

> BB 

> P 
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I don't want to fan the flames of the redundancy issue, but I want to remind folks of a 
simple single collumn redundancy technique that minimizes the risk of access time penalty. 
Without some form of nonvolatile memory (laser fuse 
etc.) it still requires some initial test etc. 
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From: Tom Laidig [tom@clio] 

Sent: Wednesday, October 1 9, 1 994 1 2: 1 1 PM 

To: Tom Laidig' 

Cc: 'Lisa Robinson'; 'Mark Hofmann'; Tim B. Robinson'; Tom Vo'; 'Dave Van't Hof 
Subject: Re; Phase check results on Euterpe (fwd) 


Tom Laidig writes: 

I 

|Tom Laidig writes: 

II 

||Lisa Robinson writes: 

III 

III 

|||Mark Hofmann wrote (on Tue Oct 18): 
III 

HI Tim B. Robinson writes: 

ill Going from the LVS netlist would certainly be safer. It still exists 
III in ~tbr/euterpe/verilog/bsrc/tbr_euterpe-pass 1 .spivs. 

Ill 

III However, as I understand it lisar is still waiting for a fix to spite. 
Ill It may not affect the phase checking problem, but it does prevent us 
III from running logic simulation, so we should be careful. 

Ill 

HI Okay. Lisa will create an edif file and I'll try the Gloss run on that. 

II 

HI -hopper 
III 

|||The spite failed see /n/nosferatu/s2/euterpe/verilog/lvs 
111 

|||Error (<stdin>.76385) - pin property is not on a subckt I/O pin 

lllgmake: *** [euterpe.edifi] Error 1 

III 

|| [and the last thing in the edif was 

HI (net (rename XB_AM„9 1__0_93_ "xb_am[0]") 

III (joined 

III (portRefXB__AM_91_0_93J 

III (portRef XB_AM (instanceRef XI P_l )))))) 

III 

|||Tom? 
II 

||Ug. I'll take a look... 
I 

| I'm not forgetting this... I thought at first that the message was 
(properly complaining about something in the spice file as modified by 
jpeppermill (spite runs peppermill to filter out leaf cells and reformat 
jthe spice deck into define-before-use order; then pipes that into a C 
jprogram), but this seems OK. I'm now trying to set it all up so I can 
(run the C program in the debugger. This takes a while... 

No, the input netlist _does_ have a problem. I was getting confused 
because spite's error message only gives a line number, and less seems 
to get line numbers confused when some lines are very long. I've 
started improving the error messages... 

The problem is in the , crl2to320' subckt (which comes from the 
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'crl2to32' schematic — the valid compiler tacks on the extra '0' 
because this schematic is customized by some parameters). There are 
actual pins named xb_am_0 through xb_am_3, but there are pin properties 
declaring xb_am_0 through xb_am_6 as inputs (oddly, ab_am_l is 
specified as an input twice). 

Dave, could you take a look at this from a spice.ex perspective? I've 
been able to reproduce the problem by running 'gecElvs crrdec' (crrdec 
is the cell that instantiates crl2to32). crl2to32 is a SIZE- 
parameterized cell, so you need to netlist from the calling cell. 
No doubt the funniness is also related to the SIZE parameterization. 


Tom L 
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From: Paul Poenisch [paulp@acteon] 

Sent: Wednesday, October 19, 1994 12:27 PM 

To: Tim B. Robinson* 

Cc: 'euterpe@acteon' 

Subject: Re: tape out scheduling 


> Tim Robinson wrote (on Wed Oct 19) : 
> 

> We intend to have tapes written for the base layers by Nov 1. It is 

> up to the fab to schedule mask generation. The metal layers will be 

> at least 2 weeks later. At this point we still have substantial work 

> to do in the SOFA to get the logic completed, debugged, routed and to 

> make timine . 
> 

If the mask shop can produce 1 reticle a day and there are ~15 reticles in the base layers 
then a delay of more than 3 weeks (15 working days) between the base layers and the metal 
layers means the mask shop will run out of work part way throught the set. (It may happen 
sooner than that if the limiter is in reticle inspection) . I think that if we can't be 
sure that the metal layers will show up before the shop runs out of tapes we should either 
send the tapes out as two separate jobs or hold the base layers for the metal layers. 
> 

> Understood. However, it is part of our plan that, process problems 

> as side, we will debug the chips by changing metal layers only, so we 

> should definitely have the mask shops expecting jobs equivalent to 

> only the second half. 
> 

I don't think this is a problem if we infact tell them "this is a complete job" for a 
metal set only. The problem is in telling them there are X reticles to be made and the 
giving them Y tapes and telling them the rest will be ready someday without giving a firm 
fixed date (and I think it would be very bad form to slip that date) . 

> Conversly, delaying the start of mask generation when we know the best 

> we can expect is one mask per day will add at least 10 days to the 

> schedule. Per mouss's equation, that can be seen to cost $800K. I 

> see the problem arising if we start the first set without the 

> reasonable expectation that the remaining tapes will be delivered 

> inside that 10 day window. 
> 

Agreed. It looks like we are out of that 10 day window with euterpe. 
> 

> From our side it is very important to be able to partition the tapeout 

> process and get the diffusion layers clean and out of our hair. If 

> the tapes sit on the shelf while we finish the job, in odrder to get 

> better service from the mask shop, that's fine with me and for the fab 

> to call I think. 
> 

> Tim 


I would suggest that we should consider holding the baseplate layers until we're sure of 
the date the metal layers will be ready or until we know they will be ready within 10 
working days. I realize this may be difficult to do but if the 1 mask shop that seams to 
be able to do our reticles decides that they aren't interested in our business anymore it 
will have a real impact on our schedule and budget. 

Paul. 
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From: 
Sent: 
To: 

Subject: 


gregg 

Wednesday, October 19, 1994 1:43 PM 
'software-checkins-dist' 
stb/apps/bench demux.c 


Update of /u/chip/chip-archive/stb/apps/bench 

In directory hts : /N/auspex/root/s42/gregg/stb/apps/bench 

Modified Files: 

demux . c 
Log Message: 

Process bitstream data a byte at a time instead of a hexlet at a time. 
This is necessary as imbedded MUSE_PTS_STREAM data must be removed. 

We now do a bits_peek (32 ) to see if a MUSE_PTS_STREAM starts at the current byte offset 
and eat 13 bytes if it does. Otherwise a byte is returned. 

Calls to exit/abort are changed to succeed(l). Success is indicated by succeed(O). This 
should cause terp to exit with either a 0 or 1 status so that reg-time can properly 
indicate the success or failure of the test. It doesn't look like it's working perfectly 
yet . 

Gregg Kellogg 

MicroUnity Systems Engineering, Inc . 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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Subject: 


Sent: 
To: 

Cc: 


From: 


noel [noel@charybdis] 

Wednesday, October 19, 1994 1:51 PM 

'glen@charybdis'; Yich@charybdis'; Tim B. Robinson'; 'woody@charybdis' 
'hestia@charybdis'; 'noel@charybdis'; 'pmayer@charybdis' 
RE: new parts 


Another turn on a dime : yesterday MURATA suddenly showed up with samples of the DC/DC 
converter. They are available and we will have volume in a couple of weeks. There is thus 
no change required ; we continue on the course we were on. 
Thank you. 
Noel X787 


From: Tim B. Robinson on Oct Mon, 1994 22:31 
Subject: new parts 
To: glen; rich; woody 
Cc: noel; pmayer; hestia 


According to noel at the electrical meeting this afternoon, we need some changes in the 
auxiliary VCO power supply because of the unavailability of the Murata converter. 

Action: glen to generate additional prt ' s as specified by noel 

Action: noel/rich to update schematic 

Action: woody prepare revised netlist for ECO 

More notes/actions to follow when I have my notes to hand. 


Tim 
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From: Jay Tomlinson [woody @luckboy] 
Sent: Wednesday, October 19, 1994 2:18 PM 
To: Tim B. Robinson' 

Cc: 'arya@aphrodite'; 'hestia@aphrodite'; 'noel@aphrodite'; 'pmayer@aphrodite'; 'tbe@aphrodite'; 
'tbr@aphrodite' 

Subject: Belated Netlist meeting notes 

Tim B. Robinson wrote (on Tue Oct 18): 
Some more things from Monday's netlist meeting. Sorry for the delay. 


We still don't have the IR out circuit defined. Probably just needs a 
resistor value change. 

Action: noel to close on this with high priority. 

woody to get netlist ready based on existing sketch so all we 

have left to do is plug in correct component values. 
I have this updated in a local copy, but a new prt is required: p370_0002 1 . 1 do 
not want to check this in until it is ECO-able. 

Jay 
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From: 
Sent: 
To: 

Subject: 


Jay Tomlinson [woody@luckboy] 
Wednesday, October 19, 1994 3:46 PM 
'mws@luckboy' 
Start Vector Address 


Mark, 


jeff informs me that the SW people expect the this to be at index 40 for both ROM and 
cerberus . 

When rich's signal is high, ROM address should be selected as we said. But when it is low 
the cerberus address I gave you is Net 0 Node 0 . This is a problem since euterpe is 
normally NetO Node 0. Therefore Jeff and thought that Net 0 Node 2 (node 1 is calliope) 
would be better which means that the address should 
be: 

Cerb_Adrs SVA 

0 0000_4000_0000_0040 

not 0 0000_6000_0010_0040 for bits 45,20 


If you have some peference, then I don't think anyone really cares about which node is 
used. 


Jay 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 
Wednesday, October 19, 1994 5:42 PM 
'Loretta Guarino' 
Re: demux.reg 


Scott and I talked with Guillermo about this last night. We determined that the best way 
to make this work is to pass a success argument to success () so that 

success (0) would indicate success and success (1) would be a failure. The reason for this 
is that the simulator takes the value of r2 with the success special opcode is executed 
and uses that as it's exit value. (It's another discussion about how this should be done 
on real hardware) . 

I modified demux.c to do this, and it seems that terp prints out "Test completed", but 
demux.reg still indicates a failure. This needs to be examined further. 

Gregg 


Gregg Kellogg 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microunity.com] 

Wednesday, October 19, 1994 5:47 PM 

'guarino' 

Re: demux.reg 


Scott and I talked with Guillermo about this last night. We determined that the best way 
to make this work is to pass a success argument to success () so that 

success (0) would indicate success and success (1) would be a failure. The reason for this 
is that the simulator takes the value of r2 with the success special opcode is executed 
and uses that as it's exit value. (It's another discussion about how this should be done 
on real hardware) . 

I modified demux.c to do this, and it seems that terp prints out "Test completed", but 
demux.reg still indicates a failure. This needs to be examined further. 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

2 55 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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From: Lisa Robinson [lisar@rhodan] 

Sent: Wednesday, October 19, 1994 5:48 PM 

To: 'tbr@rhodan' 

Subject: forwarded message from Rich McCauley 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["2340" "Wed" "19" "October" "1994" "1 1:49:51" "-0700" "Rich McCauley" "rich@pegasus " nil "65" "Re: pll" 
" A From:" nil nil "10"]) 
Return-Path: <rich@pegasus> 

Received: from pegasus.microunity.com by gaea.microunity.com (4.1/musel.3) 

idAA15161; Wed, 19 Oct 94 1 1:49:52 PDT 
Received: from localhost by pegasus.microunity.com (8.6.4/muse-sw.2) 

id LAA00703; Wed, 19 Oct 1994 11:49:51 -0700 
Message-Id: <1 994 10 1 9 1 849.LAA00703@pegasus.microunity.com> 
From: rich@pegasus (Rich McCauley) 
To: brian@rhodan 
Cc: lisar@pegasus 
Subject: Re: pll 

Date: Wed, 19 Oct 1994 11:49:51 -0700 

Right. If the vco inputs to this logic grouping aren't active, then there is no 
way of reseting the divby2. Therefore, they must obviously be driven. This 
didn't come up before since we were'nt exercising the divby2. 

rich 


> From brian@rhodan Wed Oct 19 1 1 : 3 7:52 1994 

> From: brian@rhodan (Brian Smith) 

> Subject: Re: pll 

> To: rich@pegasus (Rich McCauley) 
>Date: Wed, 19 Oct 94 11:37:49 BST 

> Cc: lisar@rhodan (Lisa Robinson) 

> X-Mailer: ELM [version 2.3 PL11] 

> Content-Length: 1749 
> 

>> 

> > I was just looking at the netlist used for your simulation and it looks out of 

> > date. There are no xbmux* cells in my present gardswart, they've all been 

> > converted to scxbmux*. So, something that needs to be rebuilt hasn't been.This 

> > is, however, probably not the problem. I wonder whether all the control lines 

> > are getting wired up to the correct cerberus bits? 
>> 

> > rich 

>> 
>> 

> > > From lisar@nosferatu Tue Oct 1 8 16:16:14 1994 

> > > Date: Tue, 1 8 Oct 1 994 1 6: 16: 1 1 -0700 

> > > From: lisar@nosferatu (Lisa Robinson) 

> > > To: brian@aphrodite (Brian Smith) 

> > > Subject: pll 

> > > cc: rich@nosferatu, tbr@nosferatu 

> > > Content-Length: 288 

>> > 
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>> > 

> > > Brian Smith wrote (on Tue Oct 18): 

>> > 

> > > 

> > > The pi 1 verification is complete and released. 

>>> 

> > > I'm trying to run a simple hermes test but cannot seem to get anything 
>>> out of pill. 

> > > There is a verilog.dump on rhodan 

> > > /s3/euterpe/verilog/bsrc/hermeseasy_0.dump and a ut on my screen. 

> > > 

> > > Lisa R. 

>> > 
> 

> It looks as if the undefined value is coming from the divide by 2. This 

> seems to be caused by an undefined RESET3 ABD0PF. This is cause by an undefined 

> RESETA_ABDOPH. This signal seems to be coming from: 

> 

> xbffdh8s PDLLO (PHI_A2P, PHI_B2P, PH1_A2P, PHI__B2P, RESETl, RESETO, 

> RESETA_ABDOPH, RESETAABNDOPH); 

> 

> RESET_0 and RESETJ are both defined. It looks as if PHI_A2P and PHI_B2P 

> are being generated from the vco clocks, which are not being driven in this 

> test. 

> 

> It seems that in bypass mode there must be a vco clock to drive reset to the 

> divide by 2 flop. I suppose in the real world this won't really matter since 

> it will come up in one state or the other. Perhaps this has already been fixed, 

> since we think we have an old version. 

> 
> 

End of forwarded message 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Wednesday, October 19, 1994 7:12 PM 

To: 'Craig Hansen' 

Cc: 'mws@clytemnestra'; 'euterpe@kephalos'; 'jeffm@kephalos' 

Subject: Re: Event Register Clears 


Craig Hansen wrote (on Wed. Oct 19) : 

By using strong ordering, the hazard is eliminated. 

I agree that would be a fix. However, at present strong ordering is off the bottom of our 
priority list and Curtis has indicated they would not make use of it. 

Tim 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 7:51 PM 
'software-checkins-dist' 
gnu-tools/si m/terp memory. h 


Update of /p/cvsroot /gnu- tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
memory .h 
Log Message: 

- Cleaned-up cache tag defns to clarify use of virtual tags vs. physical tags, and to get 
the tag protection bits defined as per current uarch. 

- Used MAJOR_TO_CYCLES when defining on-chip latencies. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 7:56 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/ lisa/ src/gnu- tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

- Used new CACHE_PTAG, DCACHE_VTAG and I CACHE_VTAG macros. 

- Fixed the reading/writing of cache tags to work with values as the hw would. 

- Traces are now always using minor cycles. 

- The clock_diff value is now signed to allow "real" time to be behind 
or ahead of the simulator's time. 

- Used MAJOR_TO_CYCLES when defining latencies. 

- Used CYCLE- related macros to remove implicit assumption that the cycle 
counter is always major cycles (or always minor cycles) . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 7:59 PM 
'software-checkins-dist' 
gnu-tools/sim/terp/calliope calliope_sim.h 


Update of /p/cvsroot/gnu- tools/sim/terp/calliope 
In directory 

calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp/calliope 

Modified Files: 

calliope_sira . h 
Log Message: 

CALLIOPE_TICKS_PER_CYCLE is one per euterpe minor cycle. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:01 PM 
'software-checkins-dist' 
gnu-tools/sim/terp cycles, h 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/ src/gnu-tools/ sim/terp 

Modified Files: 
cycles . h 
Log Message: 

Traces now always contain cycles as minor, not major. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:02 PM 
'software-checkins-dist' 

gnu-tools/sim/terp hw_calliope.h hw_calliope.c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

hw_calliope . h hw_calliope . c 
Log Message: 


- Used MAJOR_TO_CYCLES when defining throttle values. 

- Removed unused functions. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:03 PM 
'software-checkins-dist' 
gnu-tools/sim/terp sim.h 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/ src/gnu-tools/sim/terp 

Modified Files: 

sim.h 
Log Message: 

Added IS HOW MANY macro. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:06 PM 
'software-checkins-dist' 
gnu-tools/sim/terp stats. h stats. c 


Update of /p/ cvs root /gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Piles: 

stats. h stats. c 
Log Message : 

- Display statistics in terms of major cycles. 

- When listing individual instruction frequencies, mark those that are 
not actually in the hardware (either because they are OLD or FUTURE) . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:07 PM 
'software-checkins-dist' 
gnu-tools/sim/terp cycles, c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root /s6/lisa/src/gnu- tools/sim/ terp 

Modified Files: 
cycles . c 
Log Message: 

Bumped up (by arbitrary amounts) the latencies of floating-point class insns, since the hw 
doesn't even have 'era. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:18 PM 

'software-checkins-dist' 

gnu-tools/si m/terp terp.h 


Update of /p/cvs root /gnu- tools/sim/terp 

In directory calliope : /N/ auspex/root/s6/lisa/src/gnu- tools/ sim/terp 

Modified Files: 

terp . h 
Log Message: 

- Added new type " signed_clock__type M . 

- Rearranged the CYCLE- related macros; now easy to switch between keeping minor cycles or 
keeping major cycles. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:19 PM 
'software-checkins-dist' 
gnu-tools/sim/terp vjnem.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

v_mem . c 
Log Message: 

DCACHE_TAG -> DCACHE_VTAG; ICACHE_TAG -> I CACHE_VT AG 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:20 PM 
'software-checkins-dist' 
gnu-tools/sim/terp stbio.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

stbio . c 
Log Message: 

When first-enabling in set_cycle_counting ( ) , call cycle init routine. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:21 PM 
'software-checkins-dist' 
gnu-tools/sim/terp decode, c 


Update of /p/cvsroot/gnu- tools/ sim/terp 

In directory calliope : /N/auspex/root / s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
decode . c 
Log Message: 

- Modified/clarified icache tag stuff. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:21 PM 
'software-checkins-dist' 
gnu-tools/sim/terp events. c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
events . c 
Log Message: 

Clock adjustments (clock_diff, adjust, newdiff) are now signed values. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:24 PM 
'software-checkins-dist' 
gnu-tools/si m/terp execute.c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/ lisa/ src /gnu- tools/sim/terp 

Modified Files; 

execute . c 
Log Message: 

- We now have { INCR , DECR } _ { MINOR , MAJOR } _CYCLE macros; use them as appropriate. 

- Modified sim_add_timeout ( ) to not increment "not__f ast_sim" when the simulator is not 
already running. 

- Make timeouts occur at the nearest major- cycle boundary on or before the minor- cycle at 
which it is due. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, October 19, 1994 8:25 PM 
'software-checkins-dist' 
gnu-tools/sim/terp execloop.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 

exec loop. c 
Log Message: 

- DCACHE_TAG -> DCACHE_VTAG ; I CACHE_TAG -> ICACHE_VTAG . 

- Use new INCR_MINOR_CYCLE and INCR_MAJOR_CYCLE macros. 

- Use MAJOR_TO_CYCLES where needed. 
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Sent: 
To: 

Cc: 


Subject: 


From: 


Tom Karzes [karzes@MicroUnity.com] 
Wednesday, October 19, 1994 10:03 PM 
, gmo@MicroUnity.com l 
'abbott@MicroU nity.com' 
simulator bug status 


Here's the current simulator bug status: 


compress 


rotate 
expand 


passed 
passed 
passed 


extract 
field 


aborts; decode problem 


copy swap 
shuf f lemux 
select 


passed 
passed 
passed 
passed 


There is still a problem decoding gextracts . One failing case is 

guextracti2 with a shift amount of 3 . I'm not sure but I think there may be a problem 
initializing optable? I don't really know though... 

Look at ~karzes/mysoft/stb/terp-src/stb/stand/diag/xlu. c for a failing example. 
I'll look at it a bit more myself to see if I can find anything. . . 
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From: Mark Hofmann [hopper@boreas] 

Sent: Wednesday, October 1 9, 1 994 1 0:28 PM 

To: 'Bill ZuravlefF 

Cc: Vant@boreas'; Tim B. Robinson' 

Subject: Possible Tau phase errors in HZ... 


Hi bill, 

Topt and Gloss are being taught to check for possible inversions of 
signals feeding tau pins on neighboring HRflops. I've run Gloss on the 
latest checked in version of HZ and come up with 44 potential errors. I 
say "potential" because it depends on the polarity of signals that you hook 
up to the primary input "tau" pins going into HZ. Gloss _assumes_ that 
if a top-level pin is called "tau_n" then it will receive a "negative" 
(or inverted) tau signal. A priamry input pin with no qualifier or no 
"ji" in the qualifier is treated as a positive (non- inverted) net. With 
that in mind, the possible violations are lissted below. (Note that when 
I ran Gloss ran Tbr's top-level Euterpe version I got the same set 
of warnings in the HZ section). To track down these errors you need to 
look at the Edif, or probably easier, the Verilog a trace back the signal 
nets which feed each of the hr flops mentioned. I'd be happy to go 
over this with you. Here's the file of suspicious nets: 

-thanks, 
hopper 

*** Warning: Tau phase error: at least one output [q_andOph, net a3_n_10] 

of hr_l I_a3ul0 [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hzmatch__c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by- 
instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l lequlO [xbxor2df2s] driven by... 

instance hr 1 Ia3ul0 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net a3_9] 

of hr_J I_a3u9 [xbhrdh2s - negative tau] 

connects to an input [d0_ad0ph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_I l_equ9 [xbxor2dl2s] driven by... 

instance hrj I_a3u9 [xbhrdh2s : flip-flop], 
*** Warning: Tau phase error: at least one output [q_ad0ph, net a3 8] 

of hr_l I_a3u8 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch_c2hrjnatchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l l_equ8 [xbxor2df2s] driven by... 

instance hrj I_a3u8 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net a3J7] 

of hr l I_a3u7 [xbhrdh2s - negative tau] 

connects to an input [d0_ad0ph] 

of hzmatchc2hr_matchuO [xbhrdh24s - positive tau]. 
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Instance hzmatch_e2hrjnatchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_ll_equ7 [xbxor2df2s] driven by- 
instance hr_l I_a3u7 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_6] 

of hrl I_a3u6 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch_c2hr matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl ImatchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l l_equ6 [xbxor2d£2s] driven by... 

instance hr_l I_a3u6 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_5] 

of hr l I a3u5 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl I matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l I_equ5 [xbxor2df2s] driven by... 

instance hr_l I_a3u5 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net a3_4] 

of hr_l I_a3u4 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_ll_equ4 [xbxor2df2s] driven by... 

instance hr _1 1 a3u4 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_3] 

of hr_l I_a3u3 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch c2hr matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl I matchmluO [xborl ldh2s] driven by- 
instance hzmatch_c2xor2_l l_equ3 [xbxor2df2s] driven by... 

instance hr_l I_a3u3 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net a3_2] 

of hr_l I_a3u2 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l l_equ2 [xbxor2df2s] driven by... 

instance hr_l I_a3u2 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_l] 

of hr l l_a3ul [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hr_matchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l l_equl [xbxor2df2sj driven by... 

instance hr_l l_a3ul [xbhrdh2s : flip-flop]. 
***Warning: Tau phase error: at least one output [q_adOph, net a3_0] 

of hr_l I_a3u0 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_c2hr_matchu0 [xbhrdh24s - positive tau]. 

Instance hzmatch_c2hrjnatchu0 [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c2orl I matchmluO [xborl ldh2s] driven by... 

instance hzmatch_c2xor2_l l_equO [xbxor2df2s] driven by... 

instance hr_l I_a3u0 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_andOph, net a3_n_10] 
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of hr l I_a3ul0 [xbhrdh2s - negative tau] 

connects to an input [dO_ad0ph] 

of hzmatch_clhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by- 
instance hzmatch_clorl l_matchmluO [xborl ldh2s] driven by,.. 

instance hzmatch_clxor2_1 l_equlO [xbxor2df2s] driven by... 

instance hr_l I_a3ul0 [xbhrdh2s : flip-flop]. 
*** Warning; Tau phase error: at least one output [q_adOph, net a3_9] 

of hr_1 1_a3u9 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatchclhrmatchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_clorl l_matchm luO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_l l_equ9 [xbxor2df2s] driven by- 
instance hr_l I_a3u9 [xbhrdh2s ; flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_8] 

of hr_I I_a3u8 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_clhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch__clorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch clxor211equ8 [xbxor2df2s] driven by... 

instance hrl I_a3u8 [xbhrdh2s : flip-flop]. 
♦♦♦Warning: Tau phase error: at least one output [q_adOph, net a3J7] 

of hr_l I_a3u7 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_clhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_clorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_1 I_equ7 [xbxor2df2s] driven by... 

instance hr_l I_a3u7 [xbhrdh2s : flip-flop]. 
♦♦♦Warning: Tau phase error: at least one output [q_adOph, net a3_6] 

of hr I 1 a3u6 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_clhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_clorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_l l_equ6 [xbxor2df2s] driven by... 

instance hr_l I_a3u6 [xbhrdh2s : flip-flop], 
♦** Warning: Tau phase error: at least one output [q_adOph, net a3_5] 

of hr l I_a3u5 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch_clhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatchclorl ImatchmluO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_l l_equ5 [xbxor2df2s] driven by- 
instance hr l I_a3u5 [xbhrdh2s : flip-flop]. 
♦** Warning: Tau phase error: at least one output [q_adOph, net a3_4] 

of hr_l I_a3u4 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch clhr matchuO [xbhrdh24s - positive tau]. 

Instance hzmatchclhrmatchuO [xbhrdh24s : flip-flop] driven by- 
instance hzmatch c lor 1 I matchmluO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_l l_equ4 [xbxor2df2s] driven by... 

instance hr_l I_a3u4 [xbhrdh2s : flip-flop]. 
♦♦♦Warning: Tau phase error: at least one output [q_adOph, net a3_3] 

of hr_l I_a3u3 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatchclhrmatchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch clorl I matchmluO [xborl ldh2s] driven by... 
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instance hzmatch_dxor2_l l_equ3 [xbxor2df2s] driven by... 

instance hr_l I_a3u3 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [cLadOph, net a3_2] 

of hr_l I_a3u2 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch clhrmatchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_c!orl ImatchmluO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_ll_equ2 [xbxor2df2s] driven by... 

instance hr_l I_a3u2 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_l] 

of hr_l l_a3ul [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hzmatch clhr matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchu0 [xbhrdh24s : flip-flop] driven by- 
instance hzmatch_clorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_clxor2_l l_equl [xbxor2df2s] driven by- 
instance hrl l_a3ul [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_0] 

of hr_l I_a3u0 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch_clhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_clhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_clorl l_matchmluO [xborl ldh2s] driven by- 
instance hzmatch_clxor2_l l_equO [xbxor2df2s] driven by... 

instance hr_l I_a3u0 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_andOph, net a3_n_10] 

of hr_l I_a3ul0 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch hzhrjnatchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_hzhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_hzorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l lequlO [xbxor2df2s] driven by... 

instance hrl I_a3ul0 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3 9] 

of hr l I_a3u9 [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hzmatch_hzhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatchJizhrrnatchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_hzorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equ9 [xbxor2df2s] driven by... 

instance hr_l I_a3u9 [xbhrdh2s : flip-flop]. 
** * Warning: Tau phase error: at least one output [q_adOph, net a3_8] 

of hrl I_a3u8 [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hzmatch hzhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_hzhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_hzorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equ8 [xbxor2df2s] driven by... 

instance hr l I_a3u8 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_7] 

of hr_l I_a3u7 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hzmatch_hzhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_hzhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatchjizorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equ7 [xbxor2df2s] driven by... 

instance hr_l I_a3u7 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_6] 

of hr_l I_a3u6 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 
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of hzmatchhzhr _matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_hzhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatchhzorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equ6 [xbxor2dt2s] driven by... 

instance hr_l I_a3u6 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_5] 

of hr_l I_a3u5 [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hzmatchhzhrmatchuO [xbhrdh24s - positive tau]. 

Instance hzmatchhzhrjnatchuO [xbhrdh24s : flip-flop] driven by- 
instance hzmatch_hzorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equ5 [xbxor2df2s] driven by... 

instance hr_l I_a3u5 [xbhrdh2s : flip-flop], 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_4] 

of hr_l I_a3u4 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_hzhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch JizhrmatchuO [xbhrdh24s : flip-flop] driven by- 
instance hzmatch hzorl I matchmluO [xborl ldh2s] driven by... 

instance hzmatch hzxor2_l l_equ4 [xbxor2df2s] driven by... 

instance hr_l I_a3u4 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_3] 

of hr_l I_a3u3 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_hzhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatchhzhrmatchuO [xbhrdh24s : flip-flop] driven by- 
instance hzmatch_hzorll_matchm1u0 [xborl ldh2s] driven by... 

instance hzmatch hzxor2 11 equ3 [xbxor2df2s] driven by... 

instance hr_I I_a3u3 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_2] 

of hr_l I_a3u2 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch_hzhr_matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch hzhr matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_hzorll_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equ2 [xbxor2df2s] driven by- 
instance hr_l I_a3u2 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_l] 

of hr_l l_a3ul [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch Jizhr rnatchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_hzhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatch_hzorl l_matchmluO [xborl ldh2s] driven by- 
instance hzmatch_hzxor2_ll_equl [xbxor2df2s] driven by... 

instance hr_l l_a3ul [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_0] 

of hr_l I_a3u0 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hzmatch hzhr matchuO [xbhrdh24s - positive tau]. 

Instance hzmatch_hzhr_matchuO [xbhrdh24s : flip-flop] driven by... 

instance hzmatchhzorl l_matchmluO [xborl ldh2s] driven by... 

instance hzmatch_hzxor2_l l_equO [xbxor2df2s] driven by... 

instance hr_l I_a3u0 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [qLadOph, net a3_0] 

of hr_l I_a3u0 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hr 1 1_a5u0 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5u0 [xbhrdh2s : flip-flop] driven by... 

instance hr_l I_a3u0 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [ct_adOph, net a3_l] 

of hr_l l_a3ul [xbhrdh2s - negative tau] 
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connects to an input [dO_adOph] 

of hr_l l_a5ul [xbhrdh2s - positive tau]. 

Instance hr_l l_a5ul [xbhrdh2s : flip-flop] driven by... 

instance hr_ll_a3ul [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph 5 net a3_2] 

of hr_l I_a3u2 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hr_l I_a5u2 [xbhrdh2s - positive tau]. 

Instance hrl I__a5u2 [xbhrdh2s : flip-flop] driven by... 

instance hr_l I_a3u2 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_3] 

of hr l I_a3u3 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hr_3 1_a5u3 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5u3 [xbhrdh2s : flip-flop] driven by... 

instance hr_ll_a3u3 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_4] 

of hr l Ia3u4 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hr_l I_a5u4 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5u4 [xbhrdh2s : flip-flop] driven by... 

instance hr l I_a3u4 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_5] 

of hr_l I_a3u5 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hr_l I_a5u5 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5u5 [xbhrdh2s : flip-flop] driven by... 

instance hr_ll_a3u5 [xbhrdh2s : flip-flop], 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_6] 

°f hO l__ a3u6 [xbhrdh2s - negative tau] 

connects to an input [dO_adOph] 

of hr l I_a5u6 [xbhrdh2s - positive tau]. 

Instance hr l I_a5u6 [xbhrdh2s : flip-flop] driven by... 

instance hr_l I_a3u6 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_7] 

of hr_l I_a3u7 [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hr l I_a5u7 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5u7 [xbhrdh2s : flip-flop] driven by... 

instance hr Il_a3u7 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_8] 

of hr l I_a3u8 [xbhrdh2s - negative tau] 

connects to an input [dOadOph] 

of hr_l I_a5u8 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5u8 [xbhrdh2s : flip-flop] driven by... 

instance hr_ 11 _a3u8 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net a3_9] 

of hr_l I_a3u9 [xbhrdh2s - negative tau] 

connects to an input [dO adOph] 

of hr_l I_a5u9 [xbhrdh2s - positive tau]. 

Instance hr l I_a5u9 [xbhrdh2s : flip-flop] driven by... 

instance hr 11 a3u9 [xbhrdh2s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_andOph, net a3_n_10] 

of hr_l l_a3ul 0 [xbhrdh2s - negative tau] 

connects to an input [dO_andOph] 

of hr_l I_a5ul0 [xbhrdh2s - positive tau]. 

Instance hr_l I_a5ul0 [xbhrdh2s : flip-flop] driven by... 

instance hr_l I_a3ul0 [xbhrdh2s : flip-flop]. 
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From: tbr 

Sent: Wednesday, October 19, 1994 11:05 PM 

To: 'Jay Tomlinson' 

Cc: , arya@aphrodite'; 'hestia@aphrodite'; 'noel@aphrodite'; 'pmayer@aphrodite'; 

'tbe@aphrodite' 

Subject: Belated Netlist meeting notes 

Follow Up Flag: Follow up 

Flag Status: Red 


Jay Tomlinson wrote (on Wed Oct 19): 


Tim B. Robinson wrote (on Tue Oct 18): 
Some more things from Monday's netlist meeting. Sorry for the delay. 


We still don't have the IR out circuit defined. Probably just needs a 
resistor value change. 

Action: noel to close on this with high priority. 

woody to get netlist ready based on existing sketch so all we 

have left to do is plug in correct component values. 
I have this updated in a local copy, but a new pit is required: p370_00021. 1 do 
not want to check this in until it is ECO-able. 

OK, I asked glen to add both the parts in your last message. 
As soon as they are there, please release it. 

Tim 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@demeter] 
Wednesday, October 19, 1994 11:47 PM 

'Craig Hansen'; , mws@clytemnestra'; 'euterpe@kephalos'; 'jeffm@kephalos' 
Re: Event Register Clears 


Tim B. Robinson wrote (on Wed Oct 19) : 


Craig Hansen wrote {on Wed Oct 19) : 

By using strong ordering, the hazard is eliminated. 

I agree that would be a fix. However, at present 
strong ordering is off the bottom of our priority list 
and Curtis has indicated they would not make use of it. 

Actually, thinking about this further, strong ordering would rather seem to defeat the 
purpose of having "fast on-chip" status for the event register. 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr 


Thursday, October 20, 1994 12:00 AM 
'llsaf 

forwarded message from Bill Zuravleff 


Follow Up Flag: Follow up 
Flag Status: Red 

start of forwarded message (RFC 934 encapsulation) 

Return-Path: <billz@melpomene> 

Received: from melpomene.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AAO 1710; Wed, 19 Oct 94 19:11:11 PDT 
Received: from localhost by melpomene.microunity.com (8.6.4/muse-sw.2) 

id TAA20094; Wed, 19 Oct 1994 19:1 1:12 -0700 
Message-Id: <1 9941 020021 l.TAA20094@melpomene.microunity.com> 
X-Mailer: ELM [version 2.3 PL11] 
From: billz@melpomene (Bill Zuravleff) 

To: mws@me!pomene (Mark Semmelmeyer), tbr@meIpomene (Tim B. Robinson), 

dickson@melpomene (Richard Dickson), woody@melpomene (Jay Tomlinson) 
Subject: ??euinst.tdcd?? 
Date: Wed, 19 Oct 94 1 9: 1 1 : 12 PDT 

Well F*udge, 
I can't releasebom because: 

Releasing BOM in /N/ghidra/root/s2/euterpe/verilog/bsrc/uu 
mkbom: Error: euinst.tdcd missing (but in CVS/Entries), 
mkbom: 1 error found. 

Doesn't look right. And I can't find "euinst.tdcd" 
whether it's used or not. 


Help! 
billz 


end 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Thursday, October 20, 1994 12:12 AM 
To: Tim B. Robinson' 

Cc: 'Bill Zuravleff ; 'Richard Dickson'; 'doifgdemeter'; 'Mark Semmelmeyer'; 'Jay Tomlinson' 
Subject: ??euinst.tdcd?? 


Tim B. Robinson wrote (on Wed Oct 19): 


Bill Zuravleff wrote (on Wed Oct 19): 

Well F*udge, 
I can't releasebom because: 

Releasing BOM in /N/ghidra/root/s2/euterpe/verilog/bsrc/uu 
mkbom: Error: euinst.tdcd missing (but in CVS/Entries), 
mkbom: 1 error found. 

Doesn't look right And I can't find "euinst.tdcd" 
whether it's used or not. 

Help! 
billz 

No idea what's wrong, but always copy lisar and doi on these kind of 
issues (and page if it's holding you up). 

Tim 


euinsUdcd is in the attic. I suggest just try removing it 

trying again. It isn't in the BOM or in the CVS/Entries I'm not sure 

how the message is being generated. 

Lisa R. 
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From: Tom Laidig [tom@clio] 

Sent: Thursday, October 20, 1994 12:46 AM 

To: Tim B. Robinson' 

Cc: 'lisar@rhodan'; 'paulb@mercury'; 'tom@rhodan' 
Subject: Re: pandora foils 

Tim B. Robinson writes: 


|Tom Laidig wrote (on Wed Oct 19): 

j Tim B. Robinson writes: 

j [Tom Laidig wrote (on Wed Oct 19): 

| j I just created the root directory of this tree, along with a 

j | world-writable 'doc' subdirectory in the repository (recall that the doc 

j j subdirectory needs to be world-writable so people can check out the 

j j documentation to read it). I think /u/chip/pandora will be created when 

j j the first releasebom is done (I can't releasebom it without some files 

| j in there). 

j | Why does it need to be world writeable just for people to be able to 

| jreadit? 

| Presumably to avoid having the >v file change out from under it, cvs 

j makes a short-lived lock file in the repository when it checks out a 

j file. Thus you need write permission in the repository to check out a 

j copy of a file. Dumb! 

jproteus/doc does not seem to be world writable: 

jtbr@demeter ~/proteus/misc 425 % Is -Isd /u/chip/chip-archive/proteus/doc 
j 1 drwxrwsr-x 2 geert 512 Oct 18 18:57 /u/chip/chip-archive/proteus/doc 

Perhaps pandora/doc needn't be world-writable; I'm not sure. The only 
other chip/doc directory that is world-writable is euterpe/doc, which 
was set that way so the software folks could check out the euterpe 
documentation. 


Tom L 
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Sent: 

To: 

Cc: 


From: 


Paul Poenisch [pau!p@acteon] 
Thursday, October 20, 1994 10:08 AM 


Subject: 


'euterpe@acteon' 
'Albert Matthews' 
metal perforations 


Hi, 


With the resent success in solving the lift-off process flow problem we now have a little 
more information on the wide metal perforation problem. It now looks like perforations 
larger than 1 urn x 1 urn will work. This is still not certain and we will be running more 
tests in the next few days. 

I think we will be proposing a perforation rule something like: 

All holes in metal 1, metal 2, metal 3 and metal 4 must be at least 
1.0 urn (20 dbus) wide and at least 1.5 urn {30 dbus) long. 

We still don't have a handle on the maximum unperf orated metal width (and probably won't 
for at least a couple more weeks) so we'll have to make a guess on that rule. 

The question we have now is when do these rules need to be finallized to be encorporated 
into the first revision of euterpe? 


Paul. 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Thursday, October 20, 1994 10:46 AM 

To: 'Mark Semmelmeyer'; Veena@nosferatu' 

Cc: 'Richard Dickson'; 'Jeff Marr'; 'Tim B. Robinson' 

Subject: multiple step operations 

Mark Semmelmeyer wrote (on Thu Oct 20): 
I guess I got lucky. 

BOM 152.0 seems to have G(U)MUL.16 working. You can try all 
the multiple step algorithms (except GGF) now. 

Okay I have a trace of the dpgmulshort test run on the zycad. 

Veena could you look at the trace asap and let me know if you need a 
dump file and what you need dumped. 

/n/nosferatu/s2/euterpe/verilog/bsrc/res/201 094. 1 9532/results/dpgmulshort.dpo 
Lisa R. 


Design Name: z_euterpe_wrap 
Run Date: 201094 
Run ID: 19532 


Using BOM: 

Version BOM.v 152.0 1994/10/20 00:38:56 LTmws 


Simulator: z_euterpe_wrap.mif.inm was built on Thu Oct 20 4:49:04 1994 
Run started on host: nosferatu at: Thu Oct 20 06:31:50 PDT 1994 
dpelgcshort O Ran ok 

dpgmulshort 0 Creating dpgmulshort_0.dpo .... (in fail loop) Failed 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kurt Wampler [wampler@thoas] 
Thursday, October 20, 1994 11:03 AM 
'paulp@thoas' 

'al@thoas'; 'cadettes@thoas*; 'euterpe@thoas'; 'fung@thoas' 
Re: metal perforations 


Paul Poenisch writes : 


>With the resent success in solving the lift-off process flow problem we 
now 

>have a little more information on the wide metal perforation problem. 
>It now looks like perforations larger than 1 urn x 1 urn will work. This 
>is 
still 

>not certain and we will be running more tests in the next few days. 
> 

>I think we will be proposing a perforation rule something like: 
> 

> All holes in metal l, metal 2, metal 3 and metal 4 must be at 


How long does a hole have to be before its width can collapse to 0 . 5uM? 
Presumably 0 . 5uM wide slits of some length will still be allowed? 

>We still don't have a handle on the maximum unperf orated metal width 
>(and probably won't for at least a couple more weeks) so we'll have to 
>make a 
guess 

>on that rule. 

If we can rely on the back-end perforator for compliance with this rule, 
I think it's pretty much just a matter of setting a variable in the 
fracture flow to whatever maximum metal width we decide to allow. 
Rather 

than just blindly issuing a rule and having us cadettes come up with 
some perforation scheme that complies with the "letter of the law" but 
violates the spirit somehow, let's work together to design a perforation 
strategy that: a) interrupts large sheets of metal as infrequently as 
possible, b) assures good adherence of metal sheets to the dielectric layers, 
c) if possible, permits good airbridge etch under fatwires. I hope these 
don't turn out to be mutually exclusive goals! 

>The question we have now is when do these rules need to be finallized 

>to 

be 

incorporated into the first revision of euterpe? 

If we don't have to hand-draw any of the perforations, and the perforation 
scheme is a simple checkerboard punch- out similar to what we already 
implemented, just with a different size & pitch, we can postpone the 
final decision until fracture time. If there are structures that have 
to be hand- perforated, we actually need that information now. If we 
determine that we need a more complex perforation scheme that requires 
additional algorithm development {i.e. something analogous to the 
intelligence in Dave's metal waf f lizer) , then we ought to get 
started now. 


least 


1.0 urn (20 dbus) wide and at least 1.5 urn (30 dbus) long. 


- Kurt 
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From: Jean-Yves Michel [yves@thalia] 

Sent: Thursday, October 20, 1994 11 :09 AM 

To: 'paulp@acteorV; 'vanthof@thalia' 

Cc: 'calliope@thalia' 

Subject: Re: metal perforations 


> From paulp@acteon Thu Oct 2 0 08:22:47 1994 

> From: paulp@acteon (Paul Poenisch) 

> Subject: metal perforations 

> To: euterpeOacteon 

> Date: Thu, 20 Oct 94 8:07:38 PDT 

> Cc: al@acteon (Albert Matthews) 

> X-Mailer: ELM [version 2.3 PL11] 

> Content -Length: 797 

> 

> Hi, 
> 

> With the resent success in solving the lift-off process flow problem 

> we 
now 

> have a little more information on the wide metal perforation problem. 
It 

> now looks like perforations larger than 1 urn x 1 urn will work. This 

> is 
still 

> not certain and we will be running more tests in the next few days. 
> 

> I think we will be proposing a perforation rule something like: 
> 

> All holes in metal 1, metal 2, metal 3 and metal 4 must be at 
least 

> 1.0 urn (20 dbus) wide and at least 1.5 urn (30 dbus) long. 


Does that mean that for instance, a 0 . 5u X 20u hole is not allowed? 
What about non- rectangle holes (L shape or ring shape for instance)? 

I still worry about the metal capacitor (cappt2 0pf ) . 

Dave, let me know when you start Calliope 1 deperf oration. I need to look at the metal 
capacitor and probably hand- fix the metal 2 layer. 

Note that the other capacitors are all OK for perforation and don't need fixes. Also the 
metal cap is only on calliope 1. 

Thanks . 

Jean -Yves 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Thursday, October20, 1994 11:10 AM 

To: 'staffers@aphrodite'; 'hopper@aphrodite'; 'jt@aphrodite'; 'lisar@aphrodite' 

Cc: 'ken@aphrodite' 

Subject: pandora mail group 


We are creating an new mail alias for discussions related to "pandora". This will be 
logged to a news group the same way as hestia, euterpe etc. Please let sysadmin know if 
you or any of your people would like /need to be added. 

Tim 
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From: John Campbell [solo@echidna] 

Sent: Thursday, October 20, 1 994 1 1 :31 AM 

To: Tom Vo' 

Cc: 'William Herndon'; 'B. P. Wong'; 'Dominador Tacmo"; 'Eldred Fellas'; 'Geert Rosseel'; 'Lisa 

Robinson'; 'Mike Wageman'; 'Warren R. Ong'; 'Paul Poenlsch'; 'Rich McCauley'; 'Bruce 
Bateman'; Tim B. Robinson'; Vikki Vu'; Tom Vo'; 'Drew Wlngard'; 'cadettes@echidna' 

Subject: New DRC errors. 


it appears that the folloing cells were adversly affected by the release of 


revision 15.73 

date: 1994/10/17 12:38:59 LT; author: vo; state: Exp; lines: +5 -5 Release Target: 
proteus/compass/layouts 

Release all files associated with euterpe baseplate 

Looks like _these_ cells were released at that time. 


TO: 

/ u/ chip/proteus / compas s / layout s 

-rwxr-xr-x 1 chip 30384 Oct 17 12:47 resis 

-rwxr-xr-x 1 chip 124665 Oct 17 

-rwxr-xr-x 1 chip 16751 Oct 17 

-rwxr-xr-x 1 chip 274503 Oct 17 


iy 

12:46 pl_eus_macro . ly 
12 : 44 leddigdrv . ly 
12 : 44 iocsbuf f er . ly 


FROM: 

/u/chip/mdunint/proteus/ compass /layouts 
-rwxr-xr-x 1 chip 30384 Sep 15 16:46 resis. ly 

-rwxr-xr-x 1 chip 124 665 Oct 13 20:14 pl_eus_macro . ly 

-rwxr-xr-x 1 chip 16751 Sep 15 13:34 leddigdrv . ly 

-rwxr-xr-x 1 chip 274503 Sep 2 14:23 iocsbuf fer . ly 


THE RESULT: 

leddigdrv is not drc clean ?? metal hanging 7 0microns out of cell?? 
resis took out ttl3vnew and ttle2ttl and they are not drcclean. 

i would like to get this properly reconstructed quickly. if you know about any of these 
cells and why they should or should not be released, please contact me. 

regards , 

solo a.k.a. John Campbell x516 
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From: B. P. Wong [bpw@frodo] 

Sent: Thursday, October 20, 1 994 1 1 :41 AM 

To: 'solo@frodo' 

Cc: 'bill@frodo'; 'bpwOfrodo'; 'dtacmo^frodo'; 'efelias@frodo'; 'geert@frodo'; 'lisar@frodo'; 

'mikew@frodo'; 'ong@frodo'; 'paulp@frodo'; 'rich^frodo'; 'stick@frodo'; 'tbr@frodo'; 

Vikki@frodo'; Vo@frodo'; , wingard@f^odo , ; 'cadettes@frodo' 
Subject: Re: New DRC errors. 


it appears that the folloing cells were adversly affected by the 
release of 


revision 15.73 

date: 1994/10/17 12:38:59 LT; author: vo; 
Release Target: proteus/ compass/ layouts 


State: Exp; lines: +5 -5 


> Release all files associated with euterpe baseplate 


> Looks like _these_ cells were released at that time. 

> 

> TO: 

> /u/chip/proteus/compass/layouts 

> -rwxr-xr-x 1 chip 30384 Oct 17 12:47 resis.ly 

> -rwxr-xr-x 1 chip 124 665 Oct 17 12:46 pl_eus_macro . ly 

> -rwxr-xr-x 1 chip 16751 Oct 17 12:44 leddigdrv.ly 

> -rwxr-xr-x 1 chip 274503 Oct 17 12:44 iocsbuf f er . ly 


FROM: 

/u/ chip / mdunint /proteus / compass / layouts 

-rwxr-xr-x 1 chip 30384 Sep 15 16:46 resis.ly 

-rwxr-xr-x 1 chip 124665 Oct 13 20:14 pleus_macro . ly 

-rwxr-xr-x 1 chip 16751 Sep 15 13:34 leddigdrv.ly 

-rwxr-xr-x 1 chip 274503 Sep 2 14:23 iocsbuf fer . ly 

THE RESULT: 

leddigdrv is not drc clean ?? metal hanging 70microns out of cell?? 
resis took out ttl3vnew and ttle2ttl and they are not drcclean. 

i would like to get this properly reconstructed quickly. if you know 
about any of these cells and why they should or should not be 
released, please contact me. 


regards, 
solo a.k.a. 


John Campbell x516 


Who has what action items? 


bpw 
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From: Geert Rosseel [geert@rhea] 

Sent: Thursday, October 20, 1994 11:50 AM 

To: 'geeiKgrhea' 

Subject: pager log, sender copy 


page from geert to geert: 

pageme gmake geert_euterpe- iter start : Oct_19_20 : 28 end: Oct_20_09:49 exit 
137 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Paul Poenisch [paulp@acteon] 
Thursday, October 20, 1994 11:53 AM 
'Kurt Wampler' 

'calliope@acteon'; 'Jean-Yves Michel'; 'Albert Matthews'; 'Paul Poenisch' 
Re: metal perforations 


> Kurt writes : 
> 

> Paul Poenisch writes: 


> >With the resent success in solving the lift-off process flow problem 

> >we 
now 

> >have a little more information on the wide metal perforation problem. 
It 

> >now looks like perforations larger than 1 urn x 1 urn will work. This 

> >is 
still 

> >not certain and we will be running more tests in the next few days. 

> > 

> >I think we will be proposing a perforation rule something like: 

> > 

> > All holes in metal 1, metal 2, metal 3 and metal 4 must be at 
least 

> > 1.0 urn (20 dbus) wide and at least 1.5 um (3 0 dbus) long. 
> 

> How long does a hole have to be before its width can collapse to 
0 . 5uM? 

> Presumably 0 . 5uM wide slits of some length will still be allowed? 

We're not sure about this. We do know that 1.0 um long holes don't look very good. I 
suspect that the crossover point is somewhere aroundl5 . or 2.0 um but we'll have to look 
into it further. 

Jean- Yves asked in another reply to my e-mail if "L" shaped holes have the same 
limitation. I don't know the answer to that right now but I suspect that putting a corner 
into the structure would improver the situation quite a bit (square root of 2 increase in 
feature width at the corner) . I'll check into it further. 

> 

> >We still don't have a handle on the maximum unperf orated metal width 
(and 

> >probably won't for at least a couple more weeks) so we'll have to 

> >make 
a guess 

> >on that rule . 
> 

> If we can rely on the back-end perforator for compliance with this 
rule, 

> I think it's pretty much just a matter of setting a variable in the 

> fracture flow to whatever maximum metal width we decide to allow. 
Rather 

> than just blindly issuing a rule and having us cadettes come up with 

> some perforation scheme that complies with the "letter of the law" but 

> violates the spirit somehow, let's work together to design a 
perforation 

> strategy that: a) interrupts large sheets of metal as infrequently as 

> possible, b) assures good adherence of metal sheets to the 

> dielectric 
layers , 

> c) if possible, permits good airbridge etch under f atwires . I hope 
these 

> don't turn out to be mutually exclusive goals! 
> 

I think that auto perforation at fracture should work. As for good air bridging I can 
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guarantee that if you make a metal feature that has more than about 1 . 0 urn maximum 
distance from any point to an edge (outside edge or a 

perforation) you will not completely air bridge the metal. I think that this requirement 
can be met within all the other requirements but it may make the metal line a little wider 
than you would like. 

> >The question we have now is when do these rules need to be finallized 
to be 

> incorporated into the first revision of euterpe? 
> 

> If we don't have to hand-draw any of the perforations, and the 
perforation 

> scheme is a simple checkerboard punch- out similar to what we already 

> implemented, just with a different size & pitch, we can postpone the 

> final decision until fracture time. If there are structures that have 

> to be hand-perforated, we actually need that information now. If we 

> determine that we need a more complex perforation scheme that requires 

> additional algorithm development (i.e. something analogous to the 

> intelligence in Dave's metal wafflizer) , then we ought to get 

> started now. 
> 

> - Kurt 
> 

Any idea when we will be ready to fracture these layers? 
Paul . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 20, 1994 12:24 PM 
'software-checkins-dist' 
gnu-tools/sim/terp run.c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

run. c 
Log Message: 

Updated instruction section of help message and fixed some formatting problems. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 20, 1994 12:26 PM 
'software-checkins-dist' 
gnu-tools/sim/terp cycles.c 


Update of /p/cvsroot/gnu- tools/ sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
cycles . c 
Log Message: 

Updated the load latency setting in init_latencies ( ) , and added missing 
IMUL4 and GFMUL classes to init_extra_issue { ) . 
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From: Rich McCauley [rich@pegasusj 

Sent: Thursday, October 20, 1994 12:44 PM 

To: 'paulp@acteon' 

Cc: 'euterpe@pegasus' 


Subject: Re: metal perforations 


A non-PC suggestion: 

Why not just forget about the perforations. If we adopted a rule that checked for wide 
metals and then checked for something greater than minimum space, it seems that the 
problem of CD control on the wide metals vs min. metals becomes a non_issue (that is the 
issue at stake here?) . That allows us to have wider busses which are necessary without 
the worry of some automatic cookie cutter coming along later negating the effect of having 
the wide metal in the first place. This is especially worrisome if the size of 
perforations is to increase from . 5u to at least lu! What kind of madness are we 
contemplat ing? 

Existing wide metals have been created with the intent of having at least on 
row/column of . 5u perforations. I would gladly put that . 5u into extra spacing to 
adjacent metal. Comments /tomatoes? 

rich 


> From paulp@acteon Thu Oct 20 08:22:51 1994 

> From: paulp@acteon (Paul Poenisch) 

> Subject: metal perforations 

> To: euterpe@acteon 

> Date: Thu, 2 0 Oct 94 8:07:38 PDT 

> Cc: aloacteon (Albert Matthews) 

> X-Mailer: ELM [version 2.3 PLll] 

> Content -Length: 797 
> 

> Hi, 

> 

> With the resent success in solving the lift-off process flow problem 

> we 
now 

> have a little more information on the wide metal perforation problem. 
It 

> now looks like perforations larger than 1 urn x 1 urn will work. This 

> is 
still 

> not certain and we will be running more tests in the next few days. 
> 

> I think we will be proposing a perforation rule something like: 
> 

> All holes in metal 1, metal 2, metal 3 and metal 4 must be at 
least 

> 1.0 urn (20 dbus) wide and at least 1.5 urn (3 0 dbus) long. 
> 

> We still don't have a handle on the maximum unperf orated metal width 
(and 

> probably won't for at least a couple more weeks) so we'll have to make 

> a 
guess 

> on that rule. 

> The question we have now is when do these rules need to be finallized 

> to 
be 

> encorporated into the first revision of euterpe? 
> 

> Paul. 


Exhibit C7 


Page 422 of 703 


From: Geert Rosseel [geert@rhea] 

Sent: Thursday, October 20, 1994 1:25 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert : 

pageme gmake gards/geert_euterpe- iter . garout . lis start : Oct_20 10 : 5 6 end: 
Oct_20_ll:24 exit 0 


Exhibit C7 


Page 423 of 703 


From: lisa 

Sent: Thursday, October 20, 1994 1 :39 PM 

To: 'Curtis Abbott' 

Subject: Re: ggfmu!8 


I just fixed the help message. Also, changing the extra-issue slots for gf mul ' s had been 
overlooked; I added this, too. It'll get built tonight (or earlier if gmo does a build 
today for some reason) . If you want it before then, you can use ~lisa/bin/sgi5/terp . 

lisa 
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From: Paul Poenisch [paulp@acteonj 
Sent: Thursday, October 20, 1 994 3:37 PM 
To: 'Rich McCauley' 
Cc: 'euterpe@acteon' 
Subject: Re: metal perforations 

> Rich McCauley wrote: 

> 

> A non-PC suggestion: 

> Why not just forget about the perforations. If we adopted a rule that checked 

> for wide metals and then checked for something greater than minimum space, it 

> seems that the problem of CD control on the wide metals vs min. metals becomes 

> a non_issue (that is the issue at stake here?). That allows us to have wider 

> busses which are necessary without the worry of some automatic cookie cutter 

> coming along later negating the effect of having the wide metal in the first 

> place. This is especially worrisome if the size of perforations is to increase 

> from .5u to at least lu! What kind of madness are we contemplating? 

> Existing wide metals have been created with the intent of having at 

> least on row/column of .5u perforations. I would gladly put that ,5u into 

> extra spacing to adjacent metal. Comments/tomatoes? 
> 

> rich 

> 
> 

There are three things that the metal perforations do (and which we are 
ignoring in the changes made to orchis). First the metal system we are using 
ends up with gold on the top of all metal lines, gold does not stick to 
silicon dioxide or silicon nitride wroth a damn. The result is that if we 
have "large" sheets of metal without dielectric posts sticking up through them 
we could get delamination of the metal and dielectric layers (particularly 
when we change the temperature of the wafers of die, which we do a lot). In 
this case "large" is a value that we have not determined but based on the 
fact that the layers involved are only about 0.5 um thick probably is we under 
50 um. 

The second reacon to have preforations is that the metal system we are using 
is quite soft. If you had a large sheet of metal without pillars of dielectric 
sticking up through them and you placed a bond pad on top when we bonded the 
die to the space transformer the metal would likely do a good impression of 
toothpaste. This could be avoided by not placing wide metal lines under pads 
but would limit the design somewhat. 

The final reason for having perforations in the current process only effects 
metal 3 and 4 (mostly metal 4). Air bridging works on a process that etchs 
the unwanted dielectric out from underneath the metal lines from the edges 
of those lines. Wide metal lines without addiquate perforations will not 
air bridge. This does generally effect the wide line itself (wide lines 
gnerally don't go fast) but any line under the wide one would have quiet high 
capacitance (the dielectric we are removing during air bridge has a dielectric 
constant of around 7). 

Paul. 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Thursday, October 20, 1 994 3:40 PM 

To: 'tbr@nosferatu\ , dickson@nosferatu'; 'craig@nosferatu'; 'bobm@nosferatu'; , mws@nosferatu' 
Subject: forwarded message from Veena Malwankar 

Are gmuladd4*s to be supported by the hardware? 
Lisa R. 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

[••252" "Thu" "20" "October" "1994" "12:09:15" "-0700" "Veena Malwankar" "veena@godzilla " nil "9" 
"euterpe/verify/standalone/dp dpgmulshorttest" " A From:" nil nil "10"]) 
Return -Path: <veena@godzilla> 

Received: from godzilla.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA07391; Thu, 20 Oct 94 12:09:25 PDT 
Received: from localhost by godzilla.microunity.com (8.6.4/muse-sw.2) 

id MAA03079; Thu, 20 Oct 1994 12:09:15 -0700 
Message-Id: <1 9941 0201 909.MAA03079@godzilla.microunity.com> 
From: veena@godzilla (Veena Malwankar) 

To: euterpe-checkins-dist@godzilla, lisar@godzilla, tbr@godzilla, tom@godzilla 
Subject: euterpe/verify/standalone/dp dpgmulshort.test 
Date: Thu, 20 Oct 1994 12:09:15 -0700 

Update of /u/chip/chip-archive/euterpe/verify/standalone/dp 

In directory godziUa:/N/auspex/root/s24/veena/euteipe/verify/standalone/dp 

Modified Files: 

dpgmulshorttest 
Log Message: 

removed 4 bit muladds which are no longer supported in hardware. 
End of forwarded message 
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From: Geert Rosseel [geert@rhea] 

Sent: Thursday, October 20, 1994 5:49 PM 

To: •geert@rhea' 

Subject: pager log message 


page from geert to geert: 

pageme gmake geert euterpe- iter start : Oct 20 15 : 43 end: Oct_20_15:47 exit 
1 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope] 

Thursday, October 20, 1994 6:11 PM 

'Dave Van't Hof 

'Geert Rosseel'; Tim B. Robinson'; 'Lisa Robinson'; 'Mark Hofmann'; 'John Campbell' 
euterpe baseplate 


A newer euterpe suitable for DRC : 
/n/ghidra/s5/vo/euterpe/compass/ save/euterpe . ly 

For the st/chip combination : 

/n/ghidra/s5/vo/euterpe/compass/save/real_euterpetop . ly 
st only: 

/n/ghidra/s5/vo/ euterpe/ compass/ save/euterpep . ly 

This version has all the custom blocks including the plls, cerberus , hco and hcl . 
This version has a few no connects so start LVS if there 1 re CPU cycles to spare . 
Netlist ; 

/n/ghidra/s5/vo/euterpe/compass/save/chip_euterpe-iter. spivs 


tvo 


Exhibit C7 


Page 428 of 703 


From: Fred Obermeier [fwo@pelagon] 

Sent: Thursday, October 20, 1994 6:27 PM 

To: , geert@pelagon'; , haim@pelagon'; 'hopper@pelagon'; 'tvo@pelagon'; Vanthof@pelagon' 

Cc: 'fwo@pelagon' 

Subject: Proposed euterpetop.ly change. 


Hi, 

After discussing this with the verification folks, we would like to perform LVS shorts 
check on the die without the space transformer. 

Therefore we need to have a layout cell that contains the baseplate with the inner and 
outer pad M5 labels. This new cell should replace baseplate defined in {cellname} top . ly 
with {cellname} named. 

These changes can be made to proteus/baseplate/Makef ile . base : 
See capitalized changes (CHANGE, NEW, ADDED) . 


{cellName} top. ly contains: 

I {cellName}p 

I {cellName} named 
baseplate 

N outer s.t. pad ring 
connections . 


# Checks tab frame connections. 

# space transformer instance 

# CHANGE: new cell instance instead of 

# ms3 labels . Tests tab frame 


NEW: 

{ cellName} named. ly contains: # Checks all die pad connections without 
s.t. 

# Core pad m5 node labels . 

# External m5 pad ring labels 

# Instance of baseplate (die) 


N core pads 

N outer die pads 

I baseplate 


{ cellName} p. ly contains: 
I space transformer guts 
N core pads 
N outer s.t. pad ring 


# Checks tab to core pad s.t. connections. 

# ADDED : Checks vdda_partition 

# Checks tab frame connections. 


{cellName} . ly : 
I die guts 
N outer die pads 


# No change: 

# Checks die to probe card connections. 


# External m5 
Do you see any problems with doing this? 
Fred. 


ring labels 
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From: vant [vanthof@hestia] 

Sent: Thursday, October 20, 1994 6:46 PM 

To: 'Fred Obermeier' 

Cc: 'geert@pelagon'; 'hairrKgpelagon'; 'hopper@pelagon'; 'tvo@pelagon'; Vanthof@petagon'; 

'fwo@pelagon' 

Subject: Re: Proposed euterpetop.ly change. 


Fred Obermeier writes: 


>Hi, 


>After discussing this with the verification folks, we would like to 
>perform LVS shorts check on the die without the space transformer, 
therefore we need to have a layout cell that contains the baseplate 
>with the inner and outer pad M5 labels . This new cell should replace 
>baseplate defined in {cellname} top . ly with {cellname} named. 
> 

>These changes can be made to proteus/baseplate/Makef ile .base : 
> See capitalized changes (CHANGE, NEW, ADDED) . 


>{cellName}top. ly contains: 

> I {cellNameJp 

> I {cellName} named 
baseplate 

> N outer s . t . pad ring 
connections. 


# Checks tab frame connections. 

# space transformer instance 

# CHANGE: new cell instance instead of 

# ms3 labels. Tests tab frame 


> # NEW: 
> {cellName} named. ly contains: 
s. t . 

> N core pads 

> N outer die pads 

> I baseplate 
> 

>{ cellName }p . ly contains: 

> I space transformer guts 

> N core pads 

> N outer s . t . pad ring 


# Checks all die pad connections without 

# Core pad m5 node labels. 

# External m5 pad ring labels 

# Instance of baseplate (die) 

# Checks tab to core pad s.t. connections. 

# ADDED: Checks vdda_partition 

# Checks tab frame connections . 


>{ cellName} .ly: 

> I die guts 

> N outer die pads 


# No change: 

# Checks die to probe card connections . 


# External m5 pad ring labels 

> 

>Do you see any problems with doing this? 


>Fred. 


I'm a bit confused. The {cellname} . ly currently contains the baseplate and that should 
remain the same. I thought the hierarchy would be: 


{cellName} top. ly contains: # 
N outer s.t. pad ring # 
connections . 

I { cellName }p # 
I space transformer guts 
N core pads # ADDED 

N outer s.t. pad ring # 
I {cellName} named # 
baseplate 

N core pads # 
N outer die pads # 


Checks tab frame connections. 
ms3 labels. Tests tab frame 

space transformer instance 

Checks vdda_partition 
Checks tab frame connections. 
CHANGE: new cell instance instead of 

Core pad m5 node labels. 
External m5 pad ring labels 
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I DIE {cellname} . ly # Instance of die (NOTE: DIE contains 
baseplate) 

N outer die pads # node names to run LVS with. 

I die guts # including baseplate 

I feel very uncomfortable using the baseplate instead of the die in the { cellname} named. ly 
since we are verifying the die with LVS , this should be the instance in the new {cellname} 
named . ly layout . 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! (tm) All kids love Log! #incluce 
<std_disclaim.h> 
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From: Gregg Kellogg [gregg@hts.microunity.com] 

Sent: Thursday, October 20, 1994 6:54 PM 

To: 'ericm' 

Subject: Re: (Fwd) Returned mail: Host unknown 


Forwarded mail from MAILER - DAEMON@ht s (Mail Delivery Subsystem) 

To: gregg@hts 

Transcript of session follows 550 gaea . ether .. . 550 Host unknown 

554 bugs@microunity.com... 550 Host unknown (Authoritative answer from name 
server) 

Unsent message follows 

Received: by hts (931110 . SGI/920502 .SGI) 

for bugs@microunity.com id AA185 65,- Thu, 2 0 Oct 94 16:40:05 -0700 
Date: Thu, 20 Oct 94 16:40:05 -0700 
Message-Id: <9410202340 . AA18565@hts> 
To : bugs@microunity . com 
Subject : 
From : gregg 
Reply- To: gregg 
X-Send-Pr-Version: 3.00 

>Submitter-Id: MUSE 
>Organi zat ion : 

MicroUnity Systems Engineering, Inc. 

>Conf idential : yes 

>Severity : serious 

>Priority: high 

>Category: compiler 

>Class: sw-bug 

^Synopsis: Compiler optimizes away shift. 
>Originator: Gregg Kellogg, MediaCom, 430 , 4158511355 
>Release : 
Environment : 

util.reg fails for test_bits (and others) with optimzation > 0 
description : 

The file stb/lib/util/tests/test_bits . c at line 68 should shift by some amount. 
No shift results in optimized code. 

Intermediate files test_bits.s and test_bits.i are in ~gregg/stb/lib/util/tests . 


>How-To-Repeat : 

run terp -q test_bits < Makefile, notice garbled output. 
Running with -O0 produces correct output. 


End of forwarded mail from MAILER- DAEMON@hts (Mail Delivery Subsystem) 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94 089-1015 gregg@microunity.com 
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From: Tom Vo [vo@merope] 

Sent: Thursday, October 20, 1994 6:55 PM 

To: Vanf 

Cc: 'fwo@pelagon'; 'geert@pelagon'; , haim@pelagon'; 'hopper@pelagon'; 'tvo@pelagon'; 

Vanthof@pelagon' 
Subject: Re: Proposed euterpetop.ly change. 


vant wrote .... 
> 

>Fred Obermeier writes: 
>> 

>>Hi, 
>> 

>>After discussing this with the verification folks, we would like to 
>>perform LVS shorts check on the die without the space transformer. 
>>Therefore we need to have a layout cell that contains the baseplate 
>>with the inner and outer pad M5 labels. This new cell should replace 
»baseplate defined in {cellname} top. ly with {cellname} named. 
>> 

>>These changes can be made to proteus/baseplate/Makef ile .base : 
» See capitalized changes (CHANGE, NEW, ADDED) . 
>> 

Checks tab frame connections, 
space transformer instance 
CHANGE : new cell instance instead of 


# ms3 labels. Tests tab frame 


# Checks all die pad connections without 


Core pad m5 node labels. 
External m5 pad ring labels 
Instance of baseplate (die) 


>>{cellName} top. ly contains: 
>> I {cellName}p 
>> I {cellName} named 
baseplate 

» N outer s.t, pad ring 
connections . 
>> 

>> # NEW 

>> {cellName } named. ly contains 
s.t. 

>> N core pads 
>> N outer die pads 
>> I baseplate 

» 

» {cellName} p. ly contains: 
» I space transformer guts 
>> N core pads 
>> N outer s.t. pad ring 
» 
>> 

>> {cellName} . ly: 
connections . 
>> I die guts 
>> N outer die pads 
>> 

>>Do you see any problems with doing this? 
>> 

>>Fred. 

>> 

> 

>I'm a bit confused. The {cellname} . ly currently contains the baseplate 
and 

>that should remain the same. I thought the hierarchy would be: 


# Checks tab to core pad s.t. connections. 

# ADDED: Checks vdda_partition 

# Checks tab frame connections. 


# No change: 

# Checks die to probe card 


# External m5 pad ring labels 


> {cellName} top . ly contains: # Checks tab frame connections. 

> N outer s.t. pad ring # ms3 labels. Tests tab frame 
connections . 

> I { cellName }p # space transformer instance 

> I space transformer guts 

> N core pads # ADDED: Checks vdda_j>artition 

> N outer s.t. pad ring # Checks tab frame connections. 


Exhibit C7 


Page 433 of 703 


> I {cellName} named 
baseplate 

> N core pads 

> N outer die pads 

> I DIE {cellname} . ly 
baseplate) 

> N outer die pads 

> I die guts 


>I feel very uncomfortable using the baseplate instead of the die in the 
> {cellname} named. ly since we are verifying the die with LVS, this 
>should be the instance in the new { cellname } named. ly layout. 
> 

>Dave 


Could somebody describe the verification flow ? I'm seeing "N core pads" and "N outer die 
pads" appearing several times in the hierachy and it's not obvious what labels are being 
seen by the tools . 

Also , please expand the definition of "N core pads" and how we plan to get that . 
tvo 


# CHANGE: new cell instance instead of 

# Core pad m5 node labels. 

# External m5 pad ring labels 

# Instance of die (NOTE: DIE contains 

# node names to run LVS with. 

# including baseplate 
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From: 
Sent: 
To: 


Gregg Kellogg [gregg@hts.microunity.com3 
Thursday, October 20, 1994 7:03 PM 
'bugs@microunlty.com' 


>Submitter-Id: MUSE 
>Organization : 

MicroUnity Systems Engineering, Inc. 

>Conf idential : yes 

>Severity: serious 

>Priority: high 

>Category: compiler 

>Class: sw-bug 

>Synopsis: Compiler optimizes away shift. 
>Originator: Gregg Kellogg, MediaCom, 430, 4158511355 
>Release : 
>Environment : 

util.reg fails for test_bits (and others) with optimzation > 0 
>Description: 

The file stb/lib/util/tests/test_bits . c at line 68 should shift by some amount. 
No shift results in optimized code. 

Intermediate files test_bits.s and test_bits.i are in ~gregg/stb/lib/util/tests . 


>How~To-Repeat : 

run terp -q test_bits < Makefile, notice garbled output. 
Running with -00 produces correct output. 


Gregg Kellogg 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 20, 1994 7:18 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

- Enabled more accurate simulation of the dcache . (A write into the dcache doesn't have 
an effect on the memory backing it until the writeback.) 

- This exposed a problem with memory_access ( ) -- it was writing to the wrong place when it 
was the first to write into a cache line. 
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From: Buffalo Chip [chip@melpomene] 

Sent: Thursday, October 20, 1 994 7:23 PM 

To: , billz@melpomene' 

Subject: output of euterpe/verilog/bsrc/. checkoutrc 


Thu Oct 20 17:15:11 PDT 1994 {billz Thu, 20 Oct 1994 17:14:47 -0700) euterpe/verilog/bsrc 
[Release BOM (V154.0) in euterpe/verilog/bsrc (Thu Oct 20 17:15:11 PDT 1994)] 


Dir euterpe/verilog/bsrc BOM 154.0 

32.7 .checkoutrc 
73 . 1 lcesnk.ut 
116.1 ldr_basic.ut 
1.150 Makefile 

1.44 Makefile. share 

40.23 Makefile. tst 

27.8 Makefile. vo 
2 7.11 TODO 

68.3 a__euterpe_wrap . parm 

35.3 analog_euterpe . hwc 

35.3 clockbias . hwc 

6 8.2 d_euterpe_wrap . parm 

80.5 dcells.pif 
7 . 1 doexcldlist 
80.1 dummy. rcf 

6 .264 euterpe . V 
(6 .260) 

12.6 euterpe . config 
24 . 17 euterpe . status 
6.70 euterpe_driver . V 
(6.69) 

6.28 euterpe jpads .V 

15 .41 euterpe_wrap.V 
(15.40) 

15.3 euterpe_wrap . parm 

134.1 export_obs 

119.2 expor t_subblock 
2 0.1 fake.pl 

41 . 4 genpim2 .pi 

47 . 7 gettst 

65.1 h_euterpe_wrap . parm 

12.1 hwcnets 

91.3 levellog 

134 . 2 levelmlog 
1.10 opchart 

37.4 pimlib.pl 

131.3 preptest 

70 . 2 purgetst 
131.1 runs 
134.3 runvtest 
(134.2) 

62 . 9 stashtst 

4 0.4 subblk.rcf 

52 . 5 tbr3v2e . config 

35.1 toplev. power . tab . local 

41.2 toplev. rcf 

12 . 2 tst_v2e . config 

Dir euterpe/verilog/bsrc/at BOM 16.0 

4.1 .checkoutrc 

1.6 Makefile 

1.8 at.V (1.7) 

l.l at.h 
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3 . 1 at_control . pirn 

l.l atcdwe2.pla 

1.1 atcteql.pla 

1 . 1 atcylenc . pla 

1.2 atdisallowxc .pla 
1.2 atgtmissxc . Veqn 
2.1 atnbreq . Veqn 

1.5 atpadcd. Veqn 

1 . 1 atpaselgen2 .Veqn 

1.1 atpaselgen64 . V 

1 . 1 atpaselgen8 .Veqn 

1.2 atprchk.Veqn 
1 . 1 atvabyp . Veqn 
1.1 atxcenbl.pla 
1.1 atxcfrz.Veqn 
4.1 clean-request 
1.1 genatcteql58.pl 
1.1 genatpasel.pl 
3.1 genpim.pl 

3.1 genptab.pl 

3 . 1 pimlib.pl 

Dir euterpe/verilog/bsrc/au BOM 15 . 0 

14.1 . checkout rc 

1.7 Makefile 

1.12 auindx.V 
12.1 auindx.pim 
14.1 clean- request 
12.1 genpira.pl 

12 . 1 piralib.pl 

14 . 1 power . tab . local 

Dir euterpe/verilog/bsrc/cc BOM 19.0 

9.1 . checkoutrc 

1.8 Makefile 
1.22 cc.V 
(1.18) 

1.6 CCUt 

5 . 9 cc_control . pim 
11.1 cchexcount .pla 
11.1 cclatchsel .pla 
11 . 5 ccsra.pla 

1.8 cctester.V 

1.1 cctester.h 

14.1 clean-request 

5.4 genpira.pl 

5.5 piralib.pl 

5 . 1 power . tab . local 

15.1 sntag.V 

Dir euterpe/verilog/bsrc/cdio BOM 32.0 

19.8 .checkoutrc 

1.10 Makefile 
1.16 cdio.V 
7.1 cdio.ut 

28.2 cdio_control .pim 

25.3 clean-request 
7 . 5 genpim . pi 

3 . 8 genptab . pi 

7.11 pimlib.pl 

Dir euterpe/verilog/bsrc/ce BOM 52.0 

1 . 13 Makefile 

1.7 Makefile.gards 
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1.1 ce.config 

2.11 ce_cms2ecl.V 
2.9 ce_flash.V 

17.4 ce_kybd.V 
17.2 ce_kybdcntr . V 
32.1 ce_mck.V 

2.6 ce_seg7.v 

1.4 ceclockbiasbuf . V 

1.12 cecore.V 

1.2 cedmctrl.V 

1.4 cedmctrlm.V 

1.2 cedmctrlt.V 

1.7 cedpreg.V 

1 . 1 celoosends . V 
1.7 cemaster.V 

1.6 cerb.in 

1.5 cerbctrlreg. V 

1.3 7 cerberus. V 

1 . 14 cerberus . cpif 

1 . 3 cerberus . rcf 

1.4 cerbnobreg.V 

1.2 cerbskewreg . V 

1.5 cerbtempreg . V 

1.31 cerbtest.V 
1 . 4 ceregbuf . V 

1.22 ceregcore . V 

1.11 ceslave.V 

1.3 cetstmux.V 

Dir euterpe/verilog/bsrc/cg BOM 8.0 

1.7 Makefile 

Dir euterpe/verilog/bsrc/cj BOM 68 . 0 

4 6.4 . checkout rc 

18.1 libr.ut 

18.2 liss.ut 

1.32 Makefile 

2.12 br.tst 

1.13 cj.V 
1.3 cj.h 
62.2 cj .pirn 

42.7 cj_control .pim 

13.14 cjrst.tst 

4 8.6 clean- request 

1.8 freel.tst 

42.2 genpim.pl 

47.3 genptab.pl 
11.16 hic.tst 
1.12 hold.tst 

3.14 ifbr.tst 

23.5 ifpred3-ll. tst 

20.4 ifpred3-2 . tst 

5.23 micbr.tst 
5.12 pcbhnd.tst 
42 . 3 pimlib.pl 

Dir euterpe/verilog/bsrc/ck BOM 16.0 

10.3 . checkoutrc 

1.7 Makefile 

9.1 ck.V 

I . 3 cktop . V 

II. 1 clean 

12 . 1 clean-request 

10.2 genpim.pl 

10.5 pimlib.pl 
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Dir euterpe/verilog/bsrc/cp BOM 17 . 0 

9.3 . checkout rc 

1.4 Makefile 

9.2 clean- request 

1,11 cp.V 

7.6 cp.pim 

5 . 2 genpim .pi 

5.1 pimlib.pl 

5 . 4 power . tab . local 

Dir euterpe/verilog/bsrc/ctiod BOM 7 . 0 

1.1 . checkoutrc 
1.4 Makefile 

1.2 clean- request 
1.2 ctiod.V 

6.1 ctiod.ut 

1.2 ctiodtester .V 
6 . 1 ctiodtester . h 
2.2 ctrasel.pla 
3,2 ctwasel.pla 

1 . 2 ctwe . Veqn 
1 . 1 genpim.pl 

1.3 genptab.pl 
1.3 pimlib.pl 

Dir euterpe/verilog/bsrc/ctioi BOM 8.0 

3.1 . checkoutrc 

1.2 Makefile 

4.2 clean- request 

1.3 ctioi.V 
1.1 ctioi.pim 
1.1 genpim.pl 

1.1 pimlib.pl 

4.2 power . tab. local 

Dir euterpe/verilog/bsrc/dp BOM 33.0 

1.27 Makefile 

1.32 dp.V 

1.22 dptop.V 

29.2 dpwrap.V 

13.8 mstepc.V 

Dir euterpe/verilog/bsrc/dr BOM 43.0 

32.2 .checkoutrc 

1.25 Makefile 

1 . 4 README 

33.4 clean- request 

12 . 1 clocksub 

1.17 dr.V 

1.1 dr. clocks. ut 
1.13 dr.config.h 
1.9 dr . ut 

2 0.26 dr_control .pirn 

1.2 dram. registers 

1.1 drba.pla 
7 . 8 drbank . V 

1 . 6 drbankarb . pla 

1.2 drbankcsm.pla 

3 . 4 drbanksel . Veqn 

1.3 drcd.pla 

1.2 drclockphase .pla 

1.2 drcolscram.pla 
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4.3 drconf ig2bs .pla 

1.3 drcsm. states .h 

1 . 2 drcsmdecode . pla 
10.2 drinstantiate .h 

1 . 3 droktoact . pla 

1 . 2 droktopre . pla 

1 . 1 droktoread . pla 

1.3 droktowrite .pla 
3 . 12 drout .V 

5.3 droutde2Sel .pla 

1 . 4 drpads . V 

1.2 drpagecontrolstack.pla 
1 . 2 drpagecsm . pla 

1.1 drpagev.pla 

1 . 2 drpmgen . pla 

1 . 1 drpop . pla 

3.5 drprbcsm.pla 

1.2 drrc.pla 

1 . 3 drreadcount . V 

1 . 2 drreadcount sel . pla 

1.3 drresetseq.pla 

1.2 drrowscram.pla 
1.1 drrp.pla 

1 . 5 drsamplephase . pla 

1 . 3 drseqcheck .pla 

3 . 1 drspacematch . Veqn 

6 . 1 drtagqc .pla 
1.15 drtester.V 
1.5 drtester.h 
1.7 drtop.V 
27.1 drtop2.V 

1 . 2 drwritecount . pla 
1.2 drwritedsel .pla 

2 0.9 genpim.pl 

3 9.1 genptab . pi 
20.7 pimlib.pl 
1 . 1 stripf lip 

Dir euterpe/verilog/bsrc/dr/conf ig BOM 2.0 

1.1 Makefile 

1.1 dram. datasheet . explained 

1.1 dram. datasheet .nec . 10 

1.1 dram. datasheet .nec . 12 

1.1 dram. system. datasheet 

1 . 1 marg . c 

1 . 1 system . datasheet . explained 

Dir euterpe/verilog/bsrc/dr/dram BOM 6 . 0 

1.4 Makefile 
1 . 1 README 

1.1 byl6_64m.ut 

1.1 by8_16m.ut 

1.1 by8_64m.ut 

1.1 sdram.V 

1.2 sdram.h 

1.1 sdram. small .h 

1 . 1 sdram. ut 

1 . 1 spy . h 

1.3 tester. V 
1.1 tester. h 

Dir euterpe/verilog/bsrc/dr/dram/mit BOM 4 . 0 

1,3 Makefile 

1.1 mi t subishi . sdram. model 

1.1 op . v 
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1.1 sdram.v 

Dir euterpe/verilog/bsrc/drio BOM 9.0 

3.4 . checkoutrc 

1 . 4 Makefile 

5.2 clean- request 
1.2 drio.v 

1.1 genpim.pl 

1.1 pimlib.pl 

1.1 power . tab . local 

Dir euterpe/verilog/bsrc/es BOM 60.0 

4 5.1 .checkoutrc 

1.21 Makefile 

45.2 clean- request 
5.33 es.v 

5.28 es.pim 

4 0.7 es_xlu.V 

8.15 esaddnib.V 

1.4 esalms.V 

1.21 esalu64.V 

1.4 esasum.V 

1.7 escla.V 

1.75 escntrl.V 

1.2 3 esomux.V 

1.4 estop. V 

3 7.7 genpim.pl 

37.1 pimlib.pl 

13.1 power . tab. local 

Dir euterpe/verilog/bsrc/gf BOM 17 . 0 

11.3 .checkoutrc 
1.12 Makefile 

11.2 clean-request 

9.3 genpim.pl 

1.5 gf.V 

4.4 gf.pim 

1.2 gfbit.pla 
1.10 gfbyt.V 
1.1 gftop.V 

9.1 pimlib.pl 

Dir euterpe/verilog/bsrc/gt BOM 54.0 

3 9.3 . checkoutrc 

8.3 2gtlb.ut 

9.4 3gtltgtlb.ut 
1.23 Makefile 

41.4 clean- request 
2 6.5 genpim.pl 

14.3 genpipedat.pl 

24.4 genptab.pl 
7.15 gentst.pl 
2.18 gt.V 

2 6.14 gt_control .pirn 

7.2 5 gt_driver.V 
9.2 gtdone.pl a 

2 8.1 gtibwe.pla 

10.12 gtinstantiate . h 

7.4 gtrdy.pla 
7.25 gtsnake.V 

7 . 5 gtsnakemuxctl . pi a 

7 . 6 gtspmatchearly . Veqn 
7.18 gtspmatchlate . Veqn 
7 . 4 gtwe . Veqn 
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26.8 pimlib.pl 

Dir euterpe/verilog/bsrc/hc BOM 57 . 0 

3 5.7 . checkout rc 

1.22 Makefile 

40.3 clean- request 
34.2 genpimO.pl 
32.6 genpiml.pl 
12.5 gentst.pl 
1.29 hc.V 

3.6 hc.h 

8.5 hc.ut 

17.1 hc_buf_8.V 
6.1 hc_cmp6.V 
27.10 hc_cont rol . pirn 
8 . 7 hcdevice . V 
3.15 hc_driver.V 

4.1 hc_error . Veqn 

12.2 hc_fifo8.V 

12.2 hc_f ifo8ctrl .Veqn 

3.10 hc_ostate .pla 

3 . 2 hc_parse . Veqn 

3.6 hc_prbctrl .pla 

3 . 1 hc_rxcrc . Veqn 

3 . 4 hc_sdecode . Veqn 

3 . 7 hc_sid . Veqn 

3.2 hc_tagmatch. V 
3 . 2 hc_txcrc . Veqn 
13.1 hcinstantiate .h 
2 7.2 pimlib.pl 

17.4 power . tab. local 

Dir euterpe/verilog/bsrc/hz BOM 9.0 

4.2 . checkoutrc 

1.4 Makefile 

4.1 clean- request 

4.1 genpim.pl 

1.8 hz.V 
1.1 hz . ut 

4 . 1 hz_control . pim 

1.2 hzmatch.V 

1 . 5 hztester.v 
1.1 hztester.h 
4.1 pimlib.pl 

4.1 power . tab. local 

Dir euterpe/verilog/bsrc/icc BOM 3 . 0 

1.1 Makefile 

1.1 icc.V 

2 . 1 ice . h 

1.1 iccxci6.Veqn 

1.1 iccxci7.Veqn 

Dir euterpe/verilog/bsrc/if e BOM 23.0 

18.1 .checkoutrc 

4.2 1 . Ut 
1.8 Makefile 

18.1 clean- request 

15.2 genpim.pl 

1.2 if.h 
1.5 ifbr.tst 
1.15 ife.V 

15 .4 if e_control .pirn 

1.3 iffree.tst 
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1.3 iffree5.tst 

1.3 ifhold.tst 

1.5 ifpcselil . Veqn 

1.4 ifpcseli8 . Veqn 

2.4 ifrst.tst 

1.2 i f wntdi3 . Veqn 

1.5 i f wntdi4 . Veqn 

1.4 if wntdi5 . Veqn 
15.1 pimlib.pl 

15.1 power . tab . local 

Dir euterpe/verilog/bsrc/io BOM 24.0 

9.5 . checkout rc 
1.13 Makefile 

9.8 clean-request 

8.1 genpimO.pl 
8 . 4 genpiml . pi 
22.1 ioO_control.pim 
22.1 iol_control .pirn 

6.2 io_ififo.V 

6 . 1 io_iphase . Veqn 

6.1 io_ofifo.V 

6.1 i o_opha s e . Veqn 

6.2 io_sciof f_6.V 
6.1 io_scioff_9.V 

3.1 iocount.pla 

3 . 2 iodrive . V 

3.1 iofs.Veqn 

3.6 iorate.V 
3 . 4 iosync . V 

4.7 pimlib.pl 

7 . 2 power . tab . local 

Dir euterpe/verilog/bsrc/iq BOM 39.0 

22.3 .checkoutrc 

12.1 l.ut 
1.29 Makefile 
24.5 clean-request 
2 0.4 genpim.pl 
1.21 iq.V 

20.11 iq_control .pim 

2.6 iqbr.tst 

1.9 iqfree.tst 

1.8 iqfreeS.tst 

1.8 iqhold.tst 

1.9 iqhold5.tst 

1 . 1 iqholdq2 . Veqn 

1 . 1 iqholdq7 . Veqn 

1 . 3 iqholdqq . Veqn 

2 . 2 iqhxnumi4 . Veqn 
3 . 1 iqpredq4 . Veqn 

3 . 1 iqpredq9 . Veqn 

9.2 iqrst.tst 

1 . 1 iqtrgtqs . Veqn 

2 . 1 iqvldqtS . Veqn 
20.3 pimlib.pl 

2 0.2 power . tab . local 

Dir euterpe/verilog/bsrc/lt BOM 64.0 

5 6.1 . checkoutrc 

3.2 6 Makefile 

56 . 2 clean- request 
5 6.1 genpim.pl 

5 6.1 genptab.pl 

3.61 lt.V 
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(3.60) 


5 6.5 ltcontrol . pim 

7.7 ltstldenbl . Veqn 

56 .4 pimlib.pl 

Dir euterpe/verilog/bsrc/mc BOM 32.0 

17.3 .checkoutrc 

1.11 Makefile 

17.4 clean- request 

13.5 genpim.pl 
1.14 mc.V 

6.14 mc.pim 

14 . 14 mc_xluc . V 

28.2 mc_xlud.V 
1 . 5 mcacc8 .V 

1 . 3 mcaddbyt . V 

1.1 mcadf32.V 
1.7 mcalu64.V 

1.2 mccla.V 
13 . 1 pimlib.pl 

16.1 power . tab . local 

Dir euterpe/verilog/bsrc/mg BOM 3 6.0 

14.3 lstr.ut 
1.29 Makefile 
1 . 1 dee . in 

1 . 1 dco . in 

1.3 mg . h 

8.15 mgrst.tst 
1.21 rslt.tst 

10.6 str.tst 

Dir euterpe/verilog/bsrc/mst BOM 20.0 

13.2 . checkoutrc 

1.12 Makefile 

13.3 clean- request 

11.4 genpim.pl 

1 . 2 msacc8 . V 

1.1 msadf32.V 

1.4 msbooth.V 

5.2 mscsaddSa.V 
5 . 2 mscsadd8b . V 
5.2 mscsadd8c.V 
1.2 mshotc.V 

5 . 1 msin8a .V 

5 . 1 msin8b . V 

5.1 msin8c.V 

1.2 msrcd8.v 
1.2 msrcd8a.V 

1.2 msrcd8b.V 
1.10 mst.V 

2.13 mst.pim 

I. 1 mstop.V 

II. 1 pimlib.pl 

Dir euterpe/verilog/bsrc/nb BOM 73 . 0 

46.4 . checkoutrc 

1.32 Makefile 

1 . 3 README 

4 6.6 clean-request 

31 . 10 genpim.pl 

52.3 genptab.pl 

1.4 muxffl7_l.V 
1,4 muxff!7_4.V 
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1.2 muxffl7_5.V 
1.51 nb.V 

31.6 nb.h 

31.4 nb. toplevel .ut 

14.11 nb.ut 

3 8.26 nb_control .pirn 

9.15 nbal6x64.tpl 

31.12 ribctrl.Veqn 
9.13 nbd32x64.tpl 
1.13 nbfq.V 

44.4 ribfqcount .pla 

1.3 ribf qprienc .pla 
1.5 nbf qslice .pla 

44.3 nbfulllp.pla 
12.2 nbholdof f .pla 
68.1 nbholdof f 3 .pla 
1.13 nbperiph.V 
1.12 nbpq.V 

1.3 nbpqhelper .pla 

1.3 ribpqptrbitO . Veqn 

1.5 nbpqptr slice .Veqn 

7 . 4 nbprbarb . Veqn 

7 . 2 nbprbcount . pla 

1.5 nbrq.V 

1 . 3 nbrqptrbitO . Veqn 
1.3 nbrqptrslice . Veqn 
1.45 nbtester.V 

1.8 nbtester.h 

8.1 nbvd.pla 

15 . 4 nbwe . Veqn 
31 . 10 pimlib .pi 

Dir euterpe/verilog/bsrc/nb/rf BOM 4.0 

1.3 Makefile 

1.1 rf.ut 

1.3 rflrlw.V 

1.1 rf Irlwl6wx64b.h 

1.1 rflrlw32wx64b.h 

l.l rf tester. V 

1.1 rf tester. h 

Dir euterpe/verilog/bsrc/periph BOM 8.0 

1.6 Makefile 
1 . 1 README 

1.1 p.ut 

3.2 sptest.ut 

Dir euterpe/verilog/bsrc/rf BOM 3.0 

1.2 l.tst 

1.7 Makefile 

1.3 dor f spy 

1.2 drvchk.V 

1.6 rf_l.V 
1 . 5 rf _5 . V 

1.3 rf_dec.Veqn 
1.2 run.V 

1.2 spy.V 

Dir euterpe/verilog/bsrc/rg BOM 77.0 

6 0.2 . checkoutrc 

14 . 1 lbr . ut 

14.2 le.ut 

14 . 3 lmul . ut 

1.4 5 Makefile 
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60 . 2 clean-request 

19 . 10 genpim.pl 
19.20 pimlib.pl 

19.1 power . tab . local 

29.11 rg.V : 

67.2 rg_control . pirn 
1.10 rgcr.V 

1.18 rgdp.V 

1.6 rgimm.V 

1.25 rgpc.V 

52.1 rgplrO.pla 

9.13 rgrst.tst 

1.15 rslt.tst 

Dir euterpe/verilog/bsrc/rgxmit BOM 5.0 

1.2 . checkoutrc 

1.3 Makefile 
1.1 genpim.pl 
1.1 pimlib.pl 

1.1 power . tab. local 

1.1 rgpcbrr7 .Veqn i 

1 . 1 rgwewk . Veqn 

1.3 rgxmit.V 

1 . 1 rgxmit_control . pirn 

Dir euterpe/verilog/bsrc/sr BOM 39.0 

24.4 . checkoutrc 

1.16 Makefile 

26.4 clean- request 

16.5 genpim.pl 
27.5 genptab .pi 
16.7 pimlib.pl 
2.24 sr.V 

3.4 sr.h 

1 . 2 sr_ cla . Veqn 
16.14 sr_control . pim 

1 . 8 sr_dr iver . V 

3 . 3 sr_eventl6 . Veqn 

3.4 sr_eventreg. V 

16 . 3 sr_eventreg . pim 

3 . 5 sr_evmaskl6 . V 

1.3 sr_inc4.pla 1 

1.3 sr_inc4a.pla 

2 . 4 sr_match . v 

11.1 sr_mchold.Veqn 
3 . 3 sr_radecode . pi a 
1.3 sr_timer.V 

16.2 sr_timer.pim 

3 . 2 sr_wadecode . pla 

Dir euterpe/verilog/bsrc/tst BOM 61.0 

13.2 le.ut 

13.3 libr.ut 

13.2 liss.ut 

13.3 11. ut 
13.2 lpc.ut 
13.1 lq.ut 
13.1 lstr.ut 

1.22 Makefile 

1.9 br.tst 

1.46 drvchk.V j 

6.24 job.tst 

1.10 rslt.tst ! 
3 3.8 rsrvd.tst 

1.23 rst.tst 
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1 . 15 

spy . v 

3 . 7 

tstgen 

6 . 16 

tstrst . tst 

3 . 1 

vervars 

3.4 

vew 

3.1 

vlwire 

Dir 

euterpe/verilog/bsrc/uu 

79.2 

. checkoutrc 

25 . 1 

1 . ut 

25 . 1 

le . ut 

25.2 

1 imm . ut 

25.2 

limmpc . ut 

25 . 1 

liss . ut 

25 . 1 

lnb.ut 

2 5.1 

lpc . ut 

1.57 

Makefile 

2 . 12 

br . tst 

7 8.2 

clean- request 

68.3 

genpim .pi 

68.1 

pimlib .pi 

81 . 1 

power . tab . local 

1 . 96 

uu. V 

1.26 

uu.h 

68 . 6 

uu control . pirn 

1 . 18 

uubruv. tdcd 

1 . 12 

uubruw . Veqn 

1 . 15 

uubypltncyuv. tdcd 

1 . 4 

uuchkdstr3 .Veqn 

1 . 7 

uuchkdstuw . Veqn 

1 . 7 

uudstselut . tdcd 

1 . 9 

uuf ree . tst 

1 . 14 

uuhold. tst 

1 . 13 

uuholduu . Veqn 

1 . 19 

uuimmpc .tst 

1.25 

uuimmpcut . tdcd 

24 . 9 

uuimmus .tdcd 

1 . 8 

uuisdstuv . tdcd 

1 . 1 

uuisdstuvsplit 

1 . 14 

uuissrcur . tdcd 

28 . 7 

uuj obis tux . Veqn 

63 . 4 

uumemuv .tdcd 

8 . 13 

uumic . tst 

8 . 10 

uumicut . tdcd 

9 . 7 

uumicuu . tdcd 

3 6.7 

uuprblmf rz . Veqn 

50.2 

uuprblmrll . Veqn 

50.3 

uuprblmrl2 . Veqn 

60.2 

uuprblmrl3 .Veqn 

50.3 

uuprblmr4 . Veqn 

50.2 

uuprbltnr5 . Veqn 

50.1 

uuprblmr6 . Veqn 

50.4 

uuprblmr8 . Veqn 

61 . 1 

uuprblmr 9 . Veqn 

32 . 5 

uuprblmup . Veqn 

50 . 4 

uuprblmwm . Veqn 

14 . 24 

uupreemuq . Veqn 

1 . 2 

uupsi .pla 

8 . 2 

uurbuu . Veqn 

15 . 9 

uur sit byp c uu . Veqn 

1 . 18 

uur sltbypuu . Veqn 

28.4 

uur srvd . tdcd 

15 . 14 

uurst . tst 

53 . 1 

uur stuq .pla 

76.1 

uuruptrl2 .Veqn 

84 .3 

uusteput .pla 

84 . 1 

uustepuu.pl a 
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1.10 uuthruus . tdcd 

1 . 7 uuthruut . Vegn 

1 . 2 uuwewj . Veqn 

Dir euterpe/verilog/bsrc/xlu BOM 32.0 

2 8.1 . checkout r c 

1.29 Makefile 

8 . 1 TODO 
25.1 cl.srf 
25.1 c2.srf 
26.1 C3.srf 
25.1 cs2.srf 

25.1 cs3.srf 

23.2 db_7a.srf 
21.5 dc 8a.srf 
8.12 genpim.pl 
22.4 misc2.srf 

22.3 misc3.srf 
8.12 pimlib.pl 

21.4 q_9a_7.srf 
19.10 route.pl 

2 5.1 xbus.srf 

24.2 xlu.V 
14.4 xlu.mpc 

17.3 xlu.rcf 

14.1 xlu_ctrldata-passl . rcf 

1 . 12 xlu_ctrldata . c 
17.1 xlu_ctrldata.hnets 
17.1 xlu_ctrldata . vnets 

1 . 2 xlu_la_r2 . c 

17.1 xlu_shuf f le . hnets 

17.1 xlu_shuf fie. vnets 

18.2 xlu_sr.c 

2 8.1 xlu_sr_c3 . dir 

28.1 xlu_sr_r2 . dir 

2 8.1 xlu_sr_r3 . dir 

6 . 2 xlu_tr_sl . c 

2 8.1 xlu_tr_sl .dir 

6 . 2 xlu_tr_s2 . c 

2 8.1 xlu_tr_s2 . dir 

6 . 2 xlu_tr_s3 . c 

26.1 z3.srf 

25.1 zs3.srf 

Dir euterpe/verilog/bsrc/yy BOM 17.0 

1.13 Makefile 
1.2 dob2dascii 
2.2 dotestassign 
1.17 tas.pl 

2.1 test.V 

1.1 yy.h 

1 . 4 yyunasm . V 

1 . 5 yyunasmmnesel . tdcd 
1 . 5 yyunasmmusel . tdcd 


===> running euterpe/verilog/bsrc/ . checkoutrc (Thu Oct 20 17:19:21 PDT 
1994) <=== 

pager lisar Id: B0M,v 154.0 1994/10/20 17:13:56 LT billz Exp for i in at au cc cdio ce eg 
cj ck cp ctioi ctiod dr drio es gf gt he hz ice ife io iq It mst mc nb rg rgxmit sr uu 
xlu; do \ 

gmake -C ${i} vfiles | | exit; \ 

done 

gmake [1] : Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/at 1 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f ,h at.V | /lib/epp -P -C -B | sed -e 
'/*$/d'> at.v.tmp tnv at.v.tmp at.v echo at.v atpaselgen64 . v atpasel.v atcteql58.v 
atpaselgenS . v atpaselgen2 . v atpadcd.v atprchk.v atgtmissxc.v atxcfrz.v atvabyp.v atnbreq.v 
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atcteql.v atdisallowxc . v atxcenbl.v atcylenc.v atcdwe2.v | tr ' ■ ' \012" > vfiles 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/at 1 
gmake [1] : Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/au 1 
gmake [l]: "vfiles" is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/au' 
gmake [1] : Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/cc 1 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f .h cc.V | /lib/cpp -P -C -B | sed -e 
• /*$/d'> cc. v.tmp rav cc.v.tmp cc.v echo cc.v cclatchsel . v ccsm.v | tr ' ' '\012' > vfiles 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cc 1 
gmake [1] : Entering directory 

"* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/cdio ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cdio ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ce ' 
gmake [1] : "vfiles' is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ce ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cg 1 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cg" 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cj ' 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cj ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ck" 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/ck 1 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/cp" 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/ euterpe/verilog/bsrc/cp 1 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctioi • 
gmake [1]: "vfiles" is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctioi 1 
gmake [lj : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod" 
gmake[l]: "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod' 
gmake [1]: Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/dr ' 
gmake [1] : "vfiles" is up to date, 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/dr ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/drio 1 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/drio ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/es ' 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 
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~ /N/auspex/ root/alO/chip/euterpe/verilog/bsrc/es 1 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/gf 1 
gmake [1] : "vf iles 1 is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/gf ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/gt 1 
gmake[l]: "vf iles ' is up to date, 
gmake [1]: Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/gt ■ 
gmake [lj: Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc ' 
gmake[l]: "vfiles' is up to date, 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc 1 
gmake [1] : Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/hz ' 
gmake [1]: "vfiles' is up to date, 
gmake [1]: Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/hz ' 
gmake [1] : Entering directory 

"/N/auspex/rbot/slO/chip/euterpe/verilog/bsrc/icc ' 
gmake [1]: "vfiles" is up to date, 
gmake [1]: Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/icc 1 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ife 1 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ife 1 
gmake [1]: Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/io ' 
gmake [1]: "vfiles' is up to date, 
gmake [1]: Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/ io 1 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/iq 1 
gmake [1]: "vfiles' is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/ root/slO/chip/euterpe/verilog/bsrc/iq ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/lt ' 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dif f .h lt.V j /lib/cpp -P -C -B | sed -e 
'/ A $/d'> lt.v.tmp mv lt.v.tmp lt.v echo lt.v ltstldenbl.v | tr ' 1 '\012' > vfiles 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/lt ■ 
gmake [1] : Entering directory 

" /N/auspex/ root / si 0 /chip/euterpe/verilog/bsrc /mst ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/mst 1 
gmake [1] : Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/mc 1 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/mc ' 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/nb 1 
gmake [1] : "vfiles' is up to date, 
gmake [1 ] : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/nb 1 
gmake [1] : Entering directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/rg ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [13 : Leaving directory 

"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/rg ' 
gmake [1] : Entering directory 
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"/N/auspex/root/slO/chip/euterpe/verilog/bsrc/rgxmit ' 
gmaketl]: "vfiles' is up to date, 
gmake [1] : Leaving directory 

*■ /N/ auspex/root/slO/chip/euterpe/verilog/bsrc/ rgxmit 1 
gmake [1] : Entering directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/sr • 
gmakefl]: "vfiles" is up to date, 
gmake [1] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/ sr 1 
gmake [1] : Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/uu' 
gmake [1] : "vfiles* is up to date, 
gmake [1] : Leaving directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/uu ' 
gmake [1] : Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/xlu' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/xlu ' 
rm -f vfiles 

for i in at au cc cdio ce eg cj ck cp ctioi ctiod dr drio es gf gt he hz ice ife io iq It 
mst mc nb rg rgxmit sr uu xlu; do \ 

sed -e '/ A $/d' < ${i}/vfiles | sed -e " s J x ! $ {i } / ! " » vfiles; \ done 
[finished at Thu Oct 20 17:22:33 PDT 1994 exit status 0] 
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From: Gregg Kellogg [gregg@hts.microunity.com] 

Sent: Thursday, October 20, 1994 9:14 PM 

To: 'gmo' 

Subject: tgdb vs terp 


I had a problem in demux where running it under tgdb worked fine, but when it was run 
under terp it got a read- fault at READ_CLOCK_CYCLE ( ) . 

Gregg 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Friday, October 21, 1994 10:14 AM 

To: 'dickson@nosferatu'; Veena@nosferatu'; 'mws@nosferatu' 

Cc: 'tbr@nosferatu'; 'jeffm@nosferatu' 

Subject: dpgmul ops 


Here are the results so far of running the individual tests from the 
top. 

The extracts are also queued. 
Lisa R. 

Veena the regiser file commit trace in 

/n/nosferatii/s2/euterpe/verilog/bsrc/res/20 1 094.443 1 /results/* .dpo 


Summary file is ././res/201094.443 1/summary 


Design Name: z_euterpe_wrap 
Run Date: 201094 
Run ID: 4431 


Using BOM: 

Version BOM,v 152.0 1994/10/20 00:38:56 LT mws 
Warning: Local BOM is out of date: 


File: BOM Status: Needs Checkout 

Version: 152.0 Thu Oct 20 00:46:54 1994 

RCS Version: 154.0 /p/cvsroot/euterpe/verilog/bsrc/BOM,v 

Sticky Tag: (none) 

Sticky Date: (none) 

Sticky Options: (none) 


Simulator: z_euterpe wrap.mif.mm was built on Thu Oct 20 4:49:04 1994 

Run started on host: nosferatu at: Thu Oct 20 22:51:36 PDT 1994 

dpgmuladspc8_0 (in fail loop) Failed 
dpgmuladspcl6_0 Ran ok 
dpgmuladspc32_0 Ran ok 
dpgmuladspc64_0 (looks like X's) Failed 

dpgmulspc8_0 Ran ok 

dpgmulspc 1 6_0 Ran ok 

dpgmulspc32_0 Queued .. No result 

dpgmulspc64_0 Queued .. No result 
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dpgumuladspc8_0 Queued No result 

dpgumuladspc 1 6_0 Queued . . No result 

dpgumuladspc32_0 Queued No result 

dpgumuladspc64_0 Queued .. No result 
dpgumulspc8_0 Queued .. No result 

dpgumulspcl6_0 Queued .. No result 

dpgumulspc32_0 Queued .. No result 

dpgumulspc64_0 Queued .. No result 
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From: tbr 

Sent: Thursday, October 20, 1 994 1 1 :24 PM 

To: 'Lisa Robinson' 

Cc: 'dickson@nosferatu'; 'craig@nosferatu'; 'bobm@nosferatu'; 'mws@nosferatu' 

Subject: forwarded message from Veena Malwankar 


Follow Up Flag: Follow up 
Flag Status: Red 


Lisa Robinson wrote (on Thu Oct 20): 

Are gmuladd4's to be supported by the hardware? 
Lisa R. 

We are looking at removing them to get the data path to fit. 
We have not made a final decision on this, but in the absense of 
better proposals for something to cut, we are close to makeing that 
decision. 

Tim 


tbr wrote (on Fri Oct 14): 


We are reaching a point where it's clear we can't quite cram 
everything into the main euterpe data path. We have a shortfall of 
about 20K atoms. We are running a routing experiment this weekend on 
a version in which we have deleted the 4bit group add/subtract/multiply 
operations. This looks like it will save around 15K, but the savings 
may be greater as other logic is expected to power down because of the 
reduced loading and area of the remaining logic. 

If this experiment is successful in making the datapath fit we will 
want to move rapidly to make this change permanent. Curtis has 
indicated that this is not likely to have any impact on the set top 
application, (Note there is no change to any XLU fuctionality. It 
will continue to support all operand sises down to 1 bit). 

Please speak now if 

a) You believe there will be a significant negative software impact 
from this omission. 

&& 

b) You have alternative suggestions as to what else you would prefer 
to lose first. 


Exhibit C7 


Page 456 of 703 


From: 


tbr 


Subject: 


Sent: 


To: 


Friday, October 21, 1994 12:45 AM 
'geert' 

euterpe/verilog/Makefile 


Follow Up Flag: Follow up 
Flag Status: Red 

Looks like this is out of date (uses abspath still), but I assume it's 
never been used because chiproot gets set one too high. 

I was setting up more mnemo stuff when I noticed, but I recon we gould 
get rid of it by by changing euterpe/Makefile to do a 

make -C euterpe/verilog/bsrc 


directly. 


Tim 


Exhibit C7 


Page 457 of 703 


From: Mark Hofmann [hopper@tomato] 
Sent: Friday, October 21, 1994 11:20 AM 
To: Vant@tomato' 
Cc: Tim B. Robinson' 
Subject: Tau success! 

Hi Dave, 

Okay. I ran the tbreuterpe example and I believe I'm getting the 
same 64 errors in MC that you found (and that dickson has since fixed) and 
I'm seeing no others (just as Topt is doing). 

I've released this version of Gloss. 

For the record here are my 64 errors from tbr_euterpe: 

[It's interesting that we report the errors in a slightly different 
way, since Topt goes front to back and Gloss goes back to front.] 

-thanks, 
hopper 

*** Warning-. Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [d0_and0ph] 
of mcu21 luO [xbhrdh2s - positive tau]. 
Tau chain formcu206u0:xbhrdh4s : 

Instance mcu2I6uO:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iu0:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iu0:xbhrdh2s pin tauadlph. 
Instance mcu2UuO [xbhrdh2s : flip-flop] driven by... 
instance mcu207u0 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s ; flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [d0_and0ph] 
of mcu2 1 lu 1 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217uO:xbfTedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 lul :xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 lul :xbhrdh2s pin tau_adlph. 
Instance mcu21 lul [xbhrdh2s : flip-flop] driven by... 
instance mcu207ul [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
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connects to an input [dO_andOph] 

of mcu2I lu2 [xbhrdh2s - positive tau]. 

Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu2l Iu2:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu211u2:xbhrdh2s pin tau_adlph. 
Instance mcu21 lu2 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u2 [xbmux2dh2s] driven by- 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO andOph] 
of mcu21 lu3 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbfredh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tauadlph. 
Tau chain for mcu21 Iu3:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iu3:xbhrdh2s pin tau adlph. 
Instance mcu21 lu3 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u3 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu21 lu4 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iu4:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iu4:xbhrdh2s pin tau adlph. 
Instance mcu21 lu4 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u4 [xbmux2dh2s] driven by- 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_and0ph] 
of mcu21 lu5 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu21 Iu5:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iu5:xbhrdh2s pin tau_adlph. 
Instance mcu21 lu5 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u5 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
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of mcu21 lu6 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0;xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tauadlph. 
Tau chain for mcu21 Iu6:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iu6:xbhrdh2s pin tau_adlph. 
Instance mcu21 lu6 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u6 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu21 lu7 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iu7:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iu7:xbhrdh2s pin tau_adlph. 
Instance mcu21 lu7 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u7 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu21 lu8 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu21 7u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu21 Iu8:xbhrdh2s : 

Instance mcu2 1 6u0:xbffedh2s pin q_andlph drives- 
instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu2I Iu8:xbhrdh2s pin tau_adlph. 
Instance mcu21 lu8 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u8 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu21 lu9 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iu9:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu2I Iu9:xbhrdh2s pin tau adlph. 
Instance mcu21 lu9 [xbhrdh2s : flip-flop] driven by- 
instance mcu207u9 [xbmux2dh2s] driven by- 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu21 lulO [xbhrdh2s - positive tau]. 


Exhibit C7 


Page 460 of 703 


Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain formcu21 Iul0:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 1 u 1 0:xbhrdh2s pin tauadlph. 
Instance mcu21 lulO [xbhrdh2s : flip-flop] driven by- 
instance mcu207ul0 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_jmdOph] 
of mcu2 Hull [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q^adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 lull :xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 lul l:xbhrdh2s pin tau_adlph. 
Instance mcu21 lul 1 [xbhrdh2s : flip-flop] driven by... 
instance mcu207ul 1 [xbmux2dh2s] driven by- 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dOadOph] 
of mcu21 lul2 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iul2:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iul2:xbhrdh2s pin tau_adlph. 
Instance mcu21 lul2 [xbhrdh2s : flip-flop] driven by- 
instance mcu207ul2 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_adOph] 
of mcu2 1 lu 1 3 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu2I7uO:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iul3:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iul3:xbhrdh2s pin tau_adlph. 
Instance mcu21 lul 3 [xbhrdh2s : flip-flop] driven by... 
instance mcu207u 13 [xbmux2dh2s] driven by- 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_adOph] 
of mcu21 lul4 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 
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Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives- 
instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iul4:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iul4:xbhrdh2s pin tau_adlph. 
Instance mcu21 lul4 [xbhrdh2s : flip-flop] driven by... 
instance mcu207ul4 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbd] 
of mcu206u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu21 lul5 [xbhrdh2s - positive tau]. 
Tau chain for mcu206u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q^andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu206u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Iul5:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu222u0:xbffedh3s pin q_andlph drives... 

instance mcu21 Iul5:xbhrdh2s pin tau_adlph. 
Instance mcu21 lul5 [xbhrdh2s : flip-flop] driven by... 
instance mcu207ul5 [xbmux2dh2s] driven by... 
instance mcu206u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu2l0u0 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q^andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu204u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu210u0:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu221u0:xbffedh3s pin q_andlph drives... 

instance mcu210u0:xbhrdh2s pin tau_adlph. 
Instance mcu210u0 [xbhrdh2s : flip-flop] driven by... 
instance mcu205u0 [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dO andOph] 
of mcu210ul [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu204u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu21 Oul :xbhrdh2s : 

Instance mcu216uO:xbfYedh2s pin q_andlph drives... 

instance mcu221u0:xbffedh3s pin q_andlph drives... 

instance mcu2 1 Ou 1 : xbhrdh2s pin tau ad 1 ph . 
Instance mcu210ul [xbhrdh2s : flip-flop] driven by... 
instance mcu205ul [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu210u2 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 
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instance mcu2 1 7u0:xbffedh2s pin q_adlph drives... 
instance mcu204u0:xbhrdh4s pin tau_adlph. 

Tau chain for mcu210u2;xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu221u0:xbffedh3s pin q_andlph drives... 
instance mcu210u2:xbhrdh2s pin tauadlph. 

Instance mcu210u2 [xbhrdh2s : flip-flop] driven by- 
instance mcu205u2 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [dO_andOph] 

of mcu210u3 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
instance mcu204u0:xbhrdh4s pin tauadlph. 

Tau chain for mcu210u3:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu22lu0:xbffedh3s pin q_andlph drives... 
instance mcu210u3:xbhrdh2s pin tau_adlph. 

Instance mcu210u3 [xbhrdh2s : flip-flop] driven by- 
instance mcu205u3 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [dOandOph] 

of mcu210u4 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu2l6u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin qLadlph drives... 
instance mcu204u0:xbhrdh4s pin tau_adlph. 

Tau chain for mcu210u4:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu221u0:xbffedh3s pin q^andlph drives... 
instance mcu210u4:xbhrdh2s pin tau ad 1 ph. 

Instance mcu210u4 [xbhrdh2s : flip-flop] driven by- 
instance mcu205u4 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [dO_adOph] 

of mcu210u5 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216uO:xbfTedh2s pin q_andlph drives... 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
instance mcu204u0:xbhrdh4s pin tau_adlph. 

Tau chain for mcu210u5;xbhrdh2s : 
Instance mcu216uO:xbfTedh2s pin q_andlph drives... 
instance mcu221u0:xbffedh3s pin q_andlph drives... 
instance mcu210u5:xbhrdh2s pin tau_adlph. 

Instance mcu210u5 [xbhrdh2s : flip-flop] driven by... 

instance mcu205u5 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop], 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [dO_adOph] 

of mcu210u6 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
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instance mcu204u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu210u6:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu221u0:xbffedh3s pin q_andlph drives... 

instance mcu210u6:xbhrdh2s pin tauadlph. 
Instance mcu210u6 [xbhrdh2s : flip-flop] driven by... 
instance mcu205u6 [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dO_adOph] 
of mcu210u7 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives- 
instance mcu204u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu210u7:xbhrdh2s : 

Instance mcu2 16u0:xbffedh2s pin q_andlph drives... 

instance mcu221u0:xbffedh3s pin q_andlph drives... 

instance mcu210u7:xbhrdh2s pin tau_adlph. 
Instance mcu210u7 [xbhrdh2s : flip-flop] driven by... 
instance mcu205u7 [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dOjindOph] 
of mcu210u8 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu2l6u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu204u0:xbhrdh4s pin tau_adlph. 
Tau chain formcu210u8:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu22 Iu0:xbffedh3s pin q_andlph drives... 

instance mcu210u8:xbhrdh2s pin tau^adlph. 
Instance mcu210u8 [xbhrdh2s : flip-flop] driven by... 
instance mcu205u8 [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu210u9 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu204u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu210u9:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu22IuO:xbffedh3s pin q_andlph drives... 

instance mcu210u9:xbhrdh2s pin tau_adlph. 
Instance mcu210u9 [xbhrdh2s : flip-flop] driven by... 
instance mcu205u9 [xbmux2dh2s] driven by- 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu210ul0 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu204u0:xbhrdh4s pin tau_adlph. 
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Tau chain formcu210ul0:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu221uO:xbffedh3s pin q_andlph drives ... 
instance mcu210ul0:xbhrdh2s pin tau_adlph. 

Instance mcu210u 10 [xbhrdh2s : flip-flop] driven by... 

instance mcu205ul0 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
** * Warning: Tau phase error: at least one output [q_ad0ph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [dOandOph] 

of mcu210ul 1 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
instance mcu204u0:xbhrdh4s pin tau_adlph. 

Tau chain for mcu210ul 1 :xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu221u0:xbffedh3s pin q_andlph drives... 
instance mcu210ul 1 :xbhrdh2s pin tau_adlph. 

Instance mcu210ul 1 [xbhrdh2s : flip-flop] driven by... 

instance mcu205ul 1 [xbmux2dh2s] driven by— 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 

of mcu204uO [xbhrdh4s - negative tau] 

connects to an input [d0_and0ph] 

of mcu2 1 0ul2 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu217u0:xbffedh2s pin a_adlph drives,., 
instance mcu204u0:xbhrdh4s pin tau_adlph. 

Tau chain for mcu210ul2:xbhrdh2s : 
Instance mcu216uO:xbfTedh2s pin q_andlph drives... 
instance mcu221u0:xbffedh3s pin q_andlph drives... 
instance mcu210uI2:xbhrdh2s pin tau_adlph. 

Instance mcu210ul2 [xbhrdh2s : flip-flop] driven by... 

instance mcu205ul2 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [d0_and0ph] 

of mcu210ul3 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
instance mcu204u0:xbhrdh4s pin tau_adlph. 

Tau chain for mcu210ul3:xbhrdh2s : 
Instance mcu216uO:xbfTedh2s pin q_andlph drives... 
instance mcu221u0:xbffedh3s pin q_andlph drives... 
instance mcu2 1 Ou 1 3 :xbhrdh2s pin tauad 1 ph. 

Instance mcu210ul3 [xbhrdh2s : flip-flop] driven by... 

instance mcu205ul3 [xbmux2dh2s] driven by... 

instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_ad0ph, net mcmsbc] 

of mcu204u0 [xbhrdh4s - negative tau] 

connects to an input [dOadOph] 

of mcu2l0ul4 [xbhrdh2s - positive tau]. 

Tau chain for mcu204u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives- 
instance mcu204u0:xbhrdh4s pin tau ad 1 ph. 

Tau chain for mcu210ul4:xbhrdh2s : 
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Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu221u0:xbffedh3s pin q_andlph drives... 

instance mcu210ul4:xbhrdh2s pin tau_adlph. 
Instance mcu210ul4 [xbhrdh2s : flip-flop] driven by- 
instance mcu205ul4 [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbc] 
of mcu204u0 [xbhrdh4s - negative tau] 
connects to an input [dO_adOph] 
of mcu210ul5 [xbhrdh2s - positive tau]. 
Tau chain for mcu204u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin CLandlph drives... 

instance mcu2]7u0:xbffedh2s pin q_adlph drives- 
instance mcu204u0:xbhrdh4s pin tauadlph. 
Tau chain for mcu210ul5:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu221u0:xbffedh3s pin q_andlph drives... 

instance mcu2 1 Ou 1 5 :xbhrdh2s pin tau_ad 1 ph. 
Instance mcu210ul5 [xbhrdh2s : flip-flop] driven by... 
instance mcu205u 15 [xbmux2dh2s] driven by... 
instance mcu204u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_adOph] 
of mcu209u0 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin qL_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu209u0:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin CLandlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 

instance mcu209u0:xbhrdh2s pin tau_adlph. 
Instance mcu209u0 [xbhrdh2s : flip-flop] driven by... 
instance mcu203u0 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu209ul [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu2I7uO:xbffedh2s pin q_adlph drives... 

instance mcu202u0;xbhrdh4s pin tau_adlph. 
Tau chain formcu209ul:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 

instance mcu209ul :xbhrdh2s pin tau_adlph. 
Instance mcu209ul [xbhrdh2s : flip-flop] driven by... 
instance mcu203u 1 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu209u2 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u2:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 
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instance mcu220uO:xbffedh3s pin qjmdlph drives... 

instance mcu209u2:xbhrdh2s pin tau_jidlph. 
Instance mcu209u2 [xbhrdh2s : flip-flop] driven by... 
instance mcu203u2 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: j au phase error: at least one output [q_adOph } net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209u3 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin qL_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau ad 1 ph. 
Tau chain for mcu209u3:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 

instance mcu209u3:xbhrdh2s pin tau_adlph. 
Instance mcu209u3 [xbhrdh2s : flip-flop] driven by- 
instance mcu203u3 [xbmux2dh2s] driven by- 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_and0ph] 
of mcu209u4 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau ad 1 ph. 
Tau chain for mcu209u4:xbhrdh2s : 

Instance mcu216uO:xbfTedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 

instance mcu209u4:xbhrdh2s pin tau_adlph. 
Instance mcu209u4 [xbhrdh2s : flip-flop] driven by... 
instance mcu203u4 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209u5 [xbhrdh2s - positive tau], 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin (L_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u5:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives ... 

instance mcu209u5:xbhrdh2s pin tau_adlph. 
Instance mcu209u5 [xbhrdh2s : flip-flop] driven by- 
instance mcu203u5 [xbmux2dh2s] driven by- 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu209u6 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu209u6:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin CL_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 
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instance mcu209u6:xbhrdh2s pin tau_adlph. 
Instance mcu209u6 [xbhrdh2s : flip-flop] driven by- 
instance mcu203u6 [xbmux2dh2s] driven by- 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209u7 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives,. . 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u7:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu220u0:xbffedh3s pin q_andlph drives- 
instance mcu209u7:xbhrdh2s pin tau_adlph. 
Instance mcu209u7 [xbhrdh2s : flip-flop] driven by- 
instance mcu203u7 [xbmux2dh2s] driven by- 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO adOph] 
of mcu209u8 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu217u0:xbffedh2s pin q_adlph drives ... 
instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u8:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu220u0:xbffedh3s pin q_andlph drives... 
instance mcu209u8:xbhrdh2s pin tauadlph. 
Instance mcu209u8 [xbhrdh2s : flip-flop] driven by- 
instance mcu203u8 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_adOph] 
of mcu209u9 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 
Instance mcu2 1 6u0:xbffedh2s pin q_andlph drives- 
instance mcu2!7u0:xbffedh2s pin q_adlph drives- 
instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u9:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu220u0:xbffedh3s pin q_andlph drives- 
instance mcu209u9:xbhrdh2s pin tau_adlph. 
Instance mcu209u9 [xbhrdh2s : flip-flop] driven by- 
instance mcu203u9 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_and0ph] 
of mcu209ul0 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu217u0:xbffedh2s pin q_adlph drives... 
instance mcu202u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu209ul0:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu220u0:xbffedh3s pin q_andlph drives... 
instance mcu209u!0:xbhrdh2s pin tau_adlph. 
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Instance mcu209ul0 [xbhrdh2s : flip-flop] driven by... 
instance mcu203ul0 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s ; flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu209ul 1 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209ul 1 :xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives ... 

instance mcu209ul l:xbhrdh2s pin tau_adlph. 
Instance mcu209ul 1 [xbhrdh2s : flip-flop] driven by... 
instance mcu203ul 1 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209ul2 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209ul2:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q^andlph drives... 

instance mcu209ul2:xbhrdh2s pin tau_adlph. 
Instance mcu209ul2 [xbhrdh2s : flip-flop] driven by- 
instance mcu203ul2 [xbmux2dh2s] driven by- 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209u!3 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu202u0:xbhrdh4s pin tauadlph. 
Tau chain for mcu209ul3:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 

instance mcu209u33:xbhrdh2s pin tau adlph. 
Instance mcu209ul3 [xbhrdh2s : flip-flop] driven by... 
instance mcu203ul3 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209ul4 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives- 
instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u!4:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu220u0:xbffedh3s pin q_andlph drives... 

instance mcu209ul4:xbhrdh2s pin tau_adlph. 
Instance mcu209u!4 [xbhrdh2s : flip-flop] driven by... 
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instance mcu203ul4 [xbmux2dh2s] driven by... 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsbb] 
of mcu202u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu209uI5 [xbhrdh2s - positive tau]. 
Tau chain for mcu202u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives- 
instance mcu202u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu209u 1 5 :xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives- 
instance mcu220u0:xbffedh3s pin CLandlph drives... 

instance mcu209ul5:xbhrdh2s pin tauadlph. 
Instance mcu209u!5 [xbhrdh2s : flip-flop] driven by- 
instance mcu203ul5 [xbmux2dh2s] driven by- 
instance mcu202u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu20QuO [xbhrdh4s - negative tau] 
connects to an input [dO_and0ph] 
of mcu208u0 [xbhrdh2s - positive tau], 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu2I7uO;xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu208u0:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q^andlph drives... 

instance mcu208u0:xbhrdh2s pin tau_ad 1 ph. 
Instance mcu208u0 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u0 [xbmux2dh2s] driven by- 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208ul [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216uO:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu208ul:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives ... 

instance mcu208ul:xbhrdh2s pin tau_adlph. 
Instance mcu208ul [xbhrdh2s : flip-flop] driven by... 
instance mcu201ul [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO adOph] 
of mcu208u2 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives ... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu208u2;xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208u2:xbhrdh2s pin tau_adlph. 
Instance mcu208u2 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u2 [xbmux2dh2s] driven by... 
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instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208u3 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu208u3:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208u3:xbhrdh2s pin tauadlph. 
Instance mcu208u3 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u3 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu208u4 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu208u4:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208u4:xbhrdh2s pin tau_adlph. 
Instance mcu208u4 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u4 [xbmux2dh2s] driven by- 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208u5 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu2I6uO:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu208u5:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208u5:xbhrdh2s pin tau_adlph. 
Instance mcu208u5 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u5 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [qLadOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO__andOph] 
of mcu208u6 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau_ad 1 ph. 
Tau chain for mcu208u6:xbhrdh2s : 

Instance mcu2 1 6u0 :xbffedh2s pin q_and 1 ph drives. . . 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208u6:xbhrdh2s pin tau_adlph. 
Instance mcu208u6 [xbhrdh2s : flip-flop] driven by- 
instance mcu201u6 [xbmux2dh2s] driven by- 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
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*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu208u7 [xbhrdh2s - positive tau], 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tauadlph. 
Tau chain for mcu208u7:xbhrdh2s : 

Instance mcu2 1 6u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin cLandlph drives- 
instance mcu208u7:xbhrdh2s pin tau adlph. 
Instance mcu208u7 [xbhrdh2s : flip-flop] driven by- 
instance mcu201u7 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu208u8 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0;xbffedh2s pin q_adlph drives- 
instance mcu200u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu208u8:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208u8:xbhrdh2s pin tau_adlph. 
Instance mcu208u8 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u8 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dOandOph] 
of mcu208u9 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau adlph. 
Tau chain for mcu208u9:xbhrdh2s : 

Instance mcu2 1 6u0:xbffedh2s pin CL_andlph drives.., 

instance mcu219uO:xbfTedh3s pin q_andlph drives... 

instance mcu208u9:xbhrdh2s pin tau_adlph. 
Instance mcu208u9 [xbhrdh2s : flip-flop] driven by- 
instance mcu201u9 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
** * Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208ul0 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives ... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0;xbhrdh4s pin tau_adlph. 
Tau chain for mcu208ul0:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin o^andlph drives... 

instance mcu2I9uO:xbffedh3s pin q_andlph drives... 

instance mcu208ul0:xbhrdh2s pin tau_adlph. 
Instance mcu208ul0 [xbhrdh2s : flip-flop] driven by... 
instance mcu201ul0 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s ; flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 


Exhibit C7 


Page 472 of 703 


of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208ul 1 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q^andlph drives... 

instance mcu217uO:xbfTedh2s pin CLadlph drives... 

instance mcu200u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu208ul 1 :xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives- 
instance mcu208ul l:xbhrdh2s pin tau_adlph. 
Instance mcu208ul 1 [xbhrdh2s ; flip-flop] driven by- 
instance mcu201ul 1 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208ul2 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu208uI2:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208ul2:xbhrdh2s pin tau_adlph. 
Instance mcu208ul2 [xbhrdh2s : flip-flop] driven by... 
instance mcu201u!2 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208ul3 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tauadlph. 
Tau chain for mcu208ul3:xbhrdh2s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin q_andlph drives... 

instance mcu208ul3:xbhrdh2s pin tau_adlph. 
Instance mcu208ul3 [xbhrdh2s : flip-flop] driven by... 
instance mcu201ul 3 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
connects to an input [dO_andOph] 
of mcu208ul4 [xbhrdh2s - positive tau]. 
Tau chain for mcu200u0:xbhrdh4s : 

Instance mcu216u0:xbffedh2s pin q_andlph drives... 

instance mcu217u0:xbffedh2s pin q_adlph drives... 

instance mcu200u0:xbhrdh4s pin tau_adlph. 
Tau chain for mcu208ul4:xbhrdh2s : 

Instance mcu216uO:xbfTedh2s pin q_andlph drives... 

instance mcu219u0:xbffedh3s pin qjmdlph drives... 

instance mcu208ul4:xbhrdh2s pin tau_adlph. 
Instance mcu208ul4 [xbhrdh2s : flip-flop] driven by- 
instance mcu201ul4 [xbmux2dh2s] driven by... 
instance mcu200u0 [xbhrdh4s : flip-flop]. 
*** Warning: Tau phase error: at least one output [q_adOph, net mcmsba] 
of mcu200u0 [xbhrdh4s - negative tau] 
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connects to an input [dOandOph] 

of mcu208ul5 [xbhrdh2s - positive tau]. 

Tau chain for mcu200u0:xbhrdh4s : 
Instance mcu216u0:xbffedh2s pin q_andlph drives... 
instance mcu217u0;xbffedh2s pin q_adlph drives- 
instance mcu200u0:xbhrdh4s pin tauadlph. 

Tau chain for mcu208ul5:xbhrdh2s : 
Instance mcu216u0:xbffedh2s pin q„andlph drives... 
instance mcu219u0:xbffedh3s pin q_andlph drives... 
instance mcu208ul5:xbhrdh2s pin tau_adlph. 

Instance mcu208u!5 [xbhrdh2s : flip-flop] driven by... 

instance mcu201ul5 [xbmux2dh2s] driven by... 

instance mcu200u0 [xbhrdh4s : flip-flop]. 
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From: Buffalo Chip [chip@rhea] 

Sent: Friday, October21, 1994 11:33 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cdio BOM 34.0 initiated by woody completed @ Fri Oct 21 
09:31:23 PDT 1994 with exit status 0.. chip 
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From: 


vant [vanthof@hestia] 


Sent: 

To: 

Cc: 


Friday, October 21, 1994 12:01 PM 
'hardheads@hestia' 


Subject: 


'Dave Van't Hof ; 'cadettesOhestia' 
new compass layer added (OPCBIk) 


I've added a new compass layer called OPCBlk. This use of this layer is strictly limited 
to assisting tapeout related functions, in particular restricting the application of OPC 
features. Any other use of this layer is forbidden. 

In order to see this new layer, please exit compass and restart. This is assuming no 
private copies of the technology files exist in local compass directories. 

If there are any questions regarding this new layer, please let me know. 


Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 


What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! (tm) All kids love Log I #incluce 
<std disclaim. h> 
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From: john mudge [mudge@hera] 

Sent: Friday, October 21 , 1994 1 :02 PM 

To: 'grahanrKgambiorix'; 'hopper@ambiorix'; *lisar@ambiorix'; , paulp@ambiorix'; 'tbr^ambiorix'; 

'geert@ambiorix' 

Cc: 'fung@hera'; 'wampler@hera'; , mudge@hera' 

Subject: Re: Tape-out schedule meetings on a regular basis ? 


Notes from the meeting. 

> An immediate discussion we should have at the first meeting is the 
status 

> of the CalliopO space- transformer : general consensus seems to be to 

> kill it (at least from the people I have talked to) . If so, we should 

> do this officially. 

$ 

This was not killed but it was put on hold. $$$$$ RIP? 

$ 
$ 
$ 

> I suggest we meet on Thursday at 11:00 to discuss the above. We can 

> then also decide if we want to have regular meetings 

This wasn't discussed and so no decision was made on whether or not we should have regular 
meetings. The default is not to have them I guess. 

Mask Status Summary. 

Mask maker Baseplate Metal 

Castor/Pollux CalliopeO Micromask all masks all masks 

150 SDEC iso. old rules 

redo . * 

CalliopeO Space Trans. Photronics some masks 

offset prob. 


Orchis Micromask all masks all masks 

150 SDEC iso. partial deperf . 
redo . * * 

Orchis Space Trans. In LVS/DRC 


Calliopel Dupont all masks on hold 

150 SDEC iso. full deperf. 
redo. ** released today 

Calliopel Space Trans. H.P. all masks 

* Being fractured/ shipped ASAP 

** being fractured/ shipped ASAP after * 

There was discussion on the best way to load our in house mask layout, verification and 
preparation as well as the mask making vendors. 

Tapeouts to come: 

Euterpe Mnemo Calliope redo Pollux redo 

Using a rough figure of 3 months to complete a tapeout (Geert) . Then we have, now-31 Dec 
for euterpe, Jan-31 Mar for Mnemo. How, when and should we fix the 

castor/pollux/calliopeO set. In the early stages of a process bring up it is not unusual 
for mask problems to be encountered. This has already occurred for the metals and SDEC 
isolation. Paul said that we may not have seen the last of metal changes. Some 
perferation may be required to provide keying for the gold which has poor adhesion and in 
the upper layers for air bridging. 

DECISIONS. 

1) CalliopeO space transformer is to be put on hold. Somebody needs to do that. Fung ?? 


Exhibit C7 


Page 477 of 703 


2) Recognizing that we are in the early stages of process bring up and there may be more 
mask changes soon it was decided to do only a first metal (18 0) fix on pollux. This would 
give us a significant improvement in yield (80%?) and give us a better opportunity to 
evaluate and debug the circuits on it. 

3) Future redos would wait until the 5.0 release of the design rules. 
Editorial comment . 

It is interesting that the release of the SDEC isolation masks was not discussed, although 
the technical issues were, and very soon after the meeting Kurt was instructed to do the 
fracture and release them. 

Meeting on regular 2 week basis probably won't cut it in terms of re-acting to problems at 
this stage but we probably need some sort of clearing house scheme. 

j ohnnymudge 


how and wf\hen to fi\x Pollux and if 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Paul Poenisch [paulp@acteon] 
Friday, October 21, 1994 1:40 PM 
'John mudge' 

'Geert Rosseel'; 'Mark Hofmann'; 'Tim B. Robinson'; 'Lisa Robinson'; 'Graham Y. Mostyn'; 
Vanthop@acteon'; Thomas Laidig'; 'Kurt Wampler' 
Re: Tape-out schedule meetings on a regular basis ? 


> 


> Using a rough figure of 3 months to complete a tapeout (Geert) . Then 

> we have, now- 31 Dec for euterpe, Jan- 31 Mar for Mnemo. How, when and 

> should we fix the castor/pollux/calliopeO set. In the early stages of 

> a process bring up it is not unusual for mask problems to be 

> encountered. This has already occurred for the metals and SDEC 

> isolation. Paul said that we may not have seen the last of metal 

> changes. Some perferation may be required to provide keying for the 

> gold which has poor adhesion and in the upper layers for air bridging. 


After talking to Al about the "do only metal 1" decision he strongly objected to my 
statement that that would fix most of the problems. I forgot that the loose poorly lifted 
metal structures might come off the wafers at some later step inside the equipment. This 
would cause a serious yield problem for real devices in the fab. Therefore I discuss the 
problem with Hopper, van't Hof and Tom and they determined that most of the work that 
needed to be done to fix all the metal layers had been done and there was only minimal 
work left to complete the fix. I tried to sent e-mail out to everyone that was at the 
meeting yesterday afternoon but managed to leave you off the list, sorry. 

The changes will involve at least metals 1 through 4. Contact pedestal, Via 45 and metal 
5 shouldn't be effected. So the minimum set will ve 4 reticles, maximum probably 7. We 
need to check with Dave on this. 


Johnny , 


Paul . 
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From: John Campbell [solo@echidna] 

Sent: Friday, October 21 , 1 994 3:07 PM 

To: Tom Vo' 

Cc: 'cadettes@echidna'; 'Geert Rosseel' 

Subject: scsofl.ly release?? 


/u/chip/euterpe/proteus/compass/layouts/scsof 1 . ly Mismatch RCS = 13,10 
/u/chip = 13 . 8 

the chip is two revs behind RCS . Is this intentional. It is the only . ly in the cells 
that i am working that is not released. 

regards , 

solo a.k.a. John Campbell x516 


Exhibit C7 


Page 480 of 703 


From: 
Sent: 
To: 

Subject: 


lisa 

Friday, October 21, 1994 5:44 PM 
'software-checki ns-dist' 
gnu-tools/sim/terp stats. c 


Update of /p/cvsroot /gnu- tools/ sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 

stats . c 
Log Message: 

Fixed printing of cache statistics when the cache is never actually used. 
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From: 
Sent: 
To: 

Subject; 


lisa 

Friday, October 21, 1994 5:50 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory.c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root /s6/lisa/ src/gnu-tools/ sim/terp 

Modified Files: 
memory . c 
Log Message : 

- Even when a cache is configured "small" (< 16k in this uarch) , all of the tags are 
readable/writable . 

- in the above case, the tags which correspond to cache lines are at the upper (higher 
address) end of the tag space, not the lower. 

- The test for "base ! = lva" exception must also check bit 47. 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Friday, October 21, 1994 6:21 PM 
To: 'Bill Zuravleff 

Cc: 'tbr@nosferatu'; 'jeffm@nosferatu'; 'woody @nosferatu'; 'dickson@nosferatu'; 'mws@nosferatu' 
Subject: Re: euterpe_driver v euterpe_wrap 

Bill Zuravleff wrote (on Fri Oct 21): 

>Today some time was spent debugging a problem in euterpe that first 
>showed up running a zycad simulation. 
>However, it turned out that the problem being debugged was 
>not not related to the original failure ... 

This week, time was spent applying the wrapper in attempts to run 
verification tests. 

Yes the wrapper really is, at its default, the bare machine. 

>but was because forces had 

>been added to the driver, configuring euterpe to have a cache and 
> memory management on. 

The reason for this is quite clear; it reduces simulation time by eliminating the 
need to write Cerberus registers, by an order of magnitude, down to a still 
lengthy 1/2 hour or so. 


>but will instead use the wrapper. 
OK, so will I. 


>I know that this has 

>been inconvienient in the past as your ut files could not be used. 

A minor inconvenience, sed or vi can be used to change the top-level module name. 

>Is it just the top-level module name that needs to be changed? 

No, into the wrapper, we should add the memlog dump, and DumpState tasks; 
the driver.log dump is already there, I believe. 

I've done this locally, but perhaps it would be an inconvenience for me to 
check this in. 

Please be aware that the required info in these logs and dumps is 

likely to change. We should strive to make it easy to change; and perphaps 

develop some simple post processing tools to examime this maelsrom of data. 

Perhaps doi can help out here to parse the logfile. 

>Also please note that NO forces should be added to euterpe_wrap UNLESS 
>they are inside an ifdef. 

Which ifdef(s) should these be inside? 
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It doesn't matter that is up to you. As long as the default target 

- gmake wrapsim - doesn't pick up any of the forces (except the force 

of POK) and that they are inside the ifdef verilog. 

Our goal is quite clear; to debug euterpe. At the moment, we've got plenty of 
bugs or non-functionality which can be excercised in 20-100 instructions after 
reset. Probably the verilog environment serves us better here. For bugs or 
non-functinality which needs 1000's of instructions to tickle, probably the 
Zycad environment - well if we're trying to simulate a gate- level representation 
of all of euterpe, hmm — is required. We should try to make it easy to run both 
simulators. 

I absolutely agree, however it is also important to set up the 
environment so that the default is to verify the "real" machine not a 
"fake" set up environment. 

Regards, 
billz 


Lisa R. 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Friday, October 21 , 1994 6:22 PM 
To: 'billz@nosferatiT; 'woody@nosferatu' 
Cc: 'tbr@nosferatu'; 'jeffm@nosferatu' 
Subject: 128 bit ops to dram 


Bill 

I re-ran dram_store_unique again since the original dump is now a 
little out of date. The files are in 

/n/rhodan/s3/euterpe/verilog/bsrc/dram_store_uniqueJv\* 

Just a reminder; if I do a 1281 store out to dram and then load it 
back the result ends up int the wrong register of the register pair. 

Lisa R. 


>From one of the original messages: 


In dbuffer: 

.octlet 0x0 12345 6789abcdef ! 1 6 
.octlet 0x0fle2d3c4b5a6978 !32 

I128bi r30, r6, 16 ! Load question 

Results in a log file entry for the register file commit. 

odd even 
3,efcdab896745230178695a4b3c2dle0f 

sl281i r30,r6, 144 

Out to dram this is: 

580440: 0, 0, 0 5 0, 0048, 14, 67452301 odd 
582000: 0, 0, 0, 0, IffT, 17, efcdab89 
585000: 0, 0, 0, 0, 004c, 14, 3c2dle0f even 
585120: 0, 0, 0, 0, Ifff, 17, 78695a4b 

Which is in the wrong order. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope] 

Friday, October 21, 1994 8:03 PM 

'Lisa Robinson' 

'Geert Rosseel'; Tim B. Robinson'; 'Mark Hofmann'; Tom Vo' 
euterpe toplevel build 


I've modified files from euterpe downward to enable a toplevel GARDS build from euterpe . 
I think you should be able to type . checkout rc from euterpe and build all the 
dcell/baseplate/gards/verilog 

To get the thing to build , I had to modified bsrc/Makef ile . tst to redefine the 
GARDS_SUBDIRS_* to include just ck . 

This will become a problem as people modified this variable to include more stuff for the 
real top level build . 

There isn't a solution for this problem at the moment . So for now people will just have 
to edit their local copy to include more stuffs 

Let me know the results , or send the log file if you encounter any problem . 


tvo 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, October 21, 1994 8:27 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

- Fixed bad casts inserted in previous fix. 

- Temporarily disabled check of address bit 47 in base vs. lva comparison. 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Saturday, October 22, 1994 9:23 AM 
To: "Mark Semmelmeyer' 

Cc: 'Bill Zuravleff ; 'Richard Dickson'; 'Eric Murray'; 'Mark Hofmann'; 'Ken Hsieh'; 'Tim B. Robinson*; 'Jay 
Tomlinson' 

Subject: rhea maybe stuck 

Mark Semmelmeyer wrote (on Sat Oct 22): 

I tried to run verilog and it said it couldn't connect to the 
license server. Gaea seems ok running 1 copy of the license 
server, but I believe verilog is trying to talk to rhea first. 
Rhea answers pings, but rsh's into it just hang. Maybe it 
needs a kick or a reboot, or maybe the problem will heal 
itself by the time I check again in the morning. One can 
test the license manager with the /u/chip/tools/bin/verlic 
program. 
Thanks. 


Yes it must be still stuck this is the message I got: 
gmake[l]: *** [euterpe] Error 1 

gmake[l]: Leaving directory '/N/auspex/rootMl/euterpe-proteus/euterpe/verilog' 
gmake: *** [euterpe] Error I 
rhea.microunity.com: Connection timed out 

When it tried to page me at bout 5:30am 


Lisa R. 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Saturday, October 22, 1 994 9:27 AM 

To: Vo@nosferatu' 

Cc: 'tbr@nosferatu'; *geert@nosferatu'; 'hopper@nosferatu'; 'vant@nosferatu'; 'tom@nosferatu' 

Subject: euterpe build 


Died around 5:30 as I hadn't cvs updated the Makefile in verilog. 

I've restarted that build so we are almost there. Tom could you take a look at the 
baseplate etc to see the build is ok. 

It is in /n/auspex/s4l/euterpe-proteus /euterpe 


Lisa R. 
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Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope] 
Saturday, October 22, 1994 12:41 PM 


'Lisa Robinson' 

'vo@nosferatu'; 'tbr@nosferatu'; 'geert@nosferatu'; 'hopper@nosferatu'; Vant@nosferatu'; 


Subject: 


'tom@nosferatu' 
Re: euterpe build 


Lisa Robinson wrote . . . . 


>Died around 5:30 as I hadn't cvs updated the Makefile in verilog. 
>I've restarted that build so we are almost there. Tom could you take a 
>look at the baseplate etc to see the build is ok. 

> 

>It is in /n/auspex/s4l/euterpe-proteus/euterpe 


> 


>Lisa R. 


You'll need to pick up changes in the baseplate area as well 
I did not release all my changes yesterday 


tvo 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@demeter] 
Saturday, October 22, 1994 12:44 PM 
'Tom Vo' 

'geert@nosferatu'; 'hopper@nosferatu'; 'Lisa Robinson'; 'tom@nosferatu\ Vant@nosferatu'; 

'vo@nosferatu' 

Re: euterpe build 


Tom Vo wrote (on Sat Oct 22) : 
Lisa Robinson wrote .... 
> 

>Died around 5:30 as I hadn't cvs updated the Makefile in verilog. 
>I've restarted that build so we are almost there. Tom could you take a 
>look at the baseplate etc to see the build is ok. 
> 

>It is in /n/auspex/s4l/euterpe-proteus/euterpe 


You'll need to pick up changes in the baseplate area as well . 
I did not release all my changes yesterday 

What else is changing? I thought we had a "final" verification run going already. 


> 


> 


>Lisa R. 


> 


Tim 
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From: Tom Vo [vo@merope] 

Sent: Saturday, October 22, 1994 12:54 PM 

To: 'Tim B. Robinson* 

Cc: 'geert@nosferatu'; 'hopper@nosferatu'; 'lisar@nosferatu'; 'tom@nosferatu'; Vant@nosferatu'; 

Vo@nosferatu" 
Subject: Re: euterpe build 


Tim B . Robinson wrote .... 

> 

> 

>Tom Vo wrote (on Sat Oct 22) : 
> 

> Lisa Robinson wrote .... 

•> > 

> > 

> >Died around 5:30 as I hadn't cvs updated the Makefile in verilog. 

> >l've restarted that build so we are almost there. Tom could you 

> take 
a 

> >look at the baseplate etc to see the build is ok. 

> > 

> >It is in /n/auspex/s41/euterpe-proteus/euterpe 


> >Lisa R. 

> > 
> 

> You'll need to pick up changes in the baseplate area as well . 

> I did not release all my changes yesterday 
> 

>What else is changing? I thought we had a "final" verification run 
>going already. 


There 1 re 2 things that did not show up from a warm build . 

Floorplan was calling xlu_shuffle dcell instead of xlu . 

Warren had this change local to his area but he never checked it in . 

Another was a custom. pif that had a couple of missing entries for the cOl generators 

I built everything from a cold start . 


tvo 
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From: 
Sent: 
To: 

Subject: 


tbr 

Saturday, October 22, 1994 1:00 PM 
•torn 1 

mnemo and pandora 


Follow Up Flag: Follow up 
Flag Status: Red 


Do you know if mail to these aliases ends up in a news group (like for 
euterpe)? (I'm not a news reader, so I'm not sure how to check). I 
had asked for it to be set up that way, but a glance at the 
etc/aliases file leads me to suspect it may not be the case. If not, 
can you get it fixed please? 


Thanks. 
Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Lisa Robinson [lisar@nosferatu] 
Saturday, October 22, 1994 1:07 PM 
Vo@nosferatu' 

'geert@nosferatu'; 'tbr@nosferatu'; 'hopper@nosferatu'; Vant@nosferatu' 
euterpe build 


Died .... 

I guess I need to update the Makefile in bsrc too. 
I'll pick up the new BOM in baseplate too. 
Lisa R. 


gmake -C verilog euterpe 
gmake [1] : Entering directory 

* /N/auspex/root/s41/euterpe-proteus/euterpe/verilog 1 
gmake DISPLAY=merope : 0 . 0 -C bsrc chip_euterpegards . chip 
gmake [2] : Entering directory 

* /N/auspex/root/s41/euterpe-proteus/euterpe/verilog/bsrc ' 

gmake [2]: *** No rule to make target " chip_euterpegards . chip ' . Stop. 

gmake [2] : Leaving directory 

""/N/auspex/ root /s41/euterpe-proteus /euterpe /verilog/bsrc ' 
gmake [1] : *** [euterpe] Error 1 
gmake [1] : Leaving directory 

* /N/auspex/root/s41/euterpe-proteus/euterpe/verilog 1 
gmake: *** [euterpe] Error 1 
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From: Tim B. Robinson [tbr@demeter] 

Sent: Saturday, October 22, 1 994 1 :07 PM 

To: Tom Vo' 

Cc: 'geert@nosferatu'; 'hopper@nosferatu'; 'lisar@nosferatu'; 'tom@nosferatu'; Vant@nosferatu'; 

Vo@nosferatu' 
Subject: Re: euterpe build 


Tom Vo wrote (on Sat Oct 22) : 
Tim B. Robinson wrote 


>Tom Vo wrote (on Sat Oct 22) : 

> 

> Lisa Robinson wrote .... 

> > 

> > 

> >Died around 5:30 as I hadn't cvs updated the Makefile in verilog. 

> >I've restarted that build so we are almost there. Tom could you 
take a 

> >look at the baseplate etc to see the build is ok. 

> > 

> >It is in /n/auspex/s41/euterpe-proteus/euterpe 

> > 

> > 

> >Lisa R. 

> > 
> 

> You'll need to pick up changes in the baseplate area as well . 

> I did not release all my changes yesterday 
> 

>What else is changing? I thought we had a "final" verification run 

>going already. 

> 

>Tim 


There' re 2 things that did not show up from a warm build . 
Floorplan was calling xlu_shuffle dcell instead of xlu . 
Warren had this change local to his area but he never checked it in . 
Another was a custom. pi f that had a couple of missing entries for 
the cOl generators . 

I built everything from a cold start , 
OK, good job we did it from a clean start. 
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From: Tom Vo [vo@merope] 

Sent: Saturday, October 22, 1994 1:12 PM 

To: Tim B. Robinson' 

Cc: 'geert@nosferatu'; 'hopper@nosferatu\ '!isar@nosferatu'; 'tom@nosferatu'; Vant@nosferatu'; 

Vo@nosferatu' 
Subject: Re: euterpe build 

Tim B . Robinson wrote .... 
> 

>Tom Vo wrote (on Sat Oct 22) : 

> 

> Tim B. Robinson wrote .... 

> > 

> > 

> >Tom Vo wrote (on Sat Oct 22) : 

> > 

> > Lisa Robinson wrote .... 

> > > 

> > > 

> > >Died around 5:30 as I hadn't cvs updated the Makefile in verilog. 

> > >I've restarted that build so we are almost there. Tom could you 
take a 

> > >look at the baseplate etc to see the build is ok. 

> > > 

> > >It is in /n/auspex/s4l/euterpe-proteus/euterpe 

> > > 

> > > 

> > >Lisa R. 

> > > 

> > 

> > You'll need to pick up changes in the baseplate area as well . 

> > I did not release all my changes yesterday 

> > 

> >What else is changing? I thought we had a "final" verification run 

> >going already. 


> There' re 2 things that did not show up from a warm build . 

> Floorplan was calling xlu_shuffle dcell instead of xlu . 

> Warren had this change local to his area but he never checked it in . 

> Another was a custom.pif that had a couple of missing entries for 

> the cOl generators . 
> 

> I built everything from a cold start . 
> 

>OK, good job we did it from a clean start. 

A clean start for me means from a cvs co , not from a getbom . 

I might have misunderstood what I was suppose to do after I made my changes . I thought 
lisar was going to do a cvs update from the top , build , then releasebom from the top to 
get the lower level release to happen . 

tvo 
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vo@microunity.com (408) 734-8100 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Saturday, October 22 T 1994 1:25 PM 
Tom Vo" 

'geert@nosferatu'; 'hopper@nosferatu'; Tim B. Robinson'; 'tom@nosferatu'; Vant@nosferatiT; 

Vo@nosferatu' 

Re: euterpe build 


Tom Vo wrote (on Sat Oct 22) : 


A clean start for me means from a cvs co , not from a getbom . 

I might have misunderstood what I was suppose to do after 

I made my changes . I thought lisar was going to 

do a cvs update from the top , build , then releasebom from the 

top to get the lower level release to happen . 


Okay - a clean start for rae is a getbom (non zero version) build and release. 

I can do a cvs update in all directories except bsrc and verify as I'm pretty sure that 
they won't build fully on an update. I'll do that. 


tvo 


Lisa R. 
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From: Tom Vo [vo@merope] 

Sent: Saturday, October 22, 1994 3:00 PM 

To: 'Lisa Robinson' 

Cc: 'geert@nosferatu'; 'hopper@nosferatu'; 'tbr@demeter'; , tom@nosferatu'; Vant@nosferatu'; 

Vo@nosferatu' 
Subject: Re: euterpe build 


Lisa Robinson wrote 


>Tom Vo wrote (on Sat Oct 22) : 


> A clean start for me means from a cvs co , not from a getbom . 

> I might have misunderstood what I was suppose to do after 

> I made my changes . I thought lisar was going to 

> do a cvs update from the top , build , then releasebom from the 

> top to get the lower level release to happen . 
> 

> tvo 
> 

>Okay - a clean start for me is a getbom (non zero version) build and 

>release . 

> 

>I can do a cvs update in all directories except bsrc and verify as I'm 
>pretty sure that they won't build fully on an update. I'll do that. 

> 

>Lisa R. 


You'll need to pick up changes to the Makefile* in bsrc , the genpim.pl file ( I think 
that's all I changed ) to build a simple euterpe layout . 

It's safer to pickup the whole bsrc directory once the verilog portion builds -- there' re 
just too many files there to remember what changed . 

tvo 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Saturday, October 22, 1994 4:41 PM 

To: Vo@nosferatu' 

Cc: Vant@nosferatu'; 'geert@nosferatu'; 'tbr@nosferatu'; 'tom@nosferatu'; 'hopper@nosferatu' 

Subject: euterpe build 


okay 

I have done a update in bsrc, run a simulation and tried a top level build. The result of 
which is in makerrs4 . 

Should I releasebom this? 


Lisa R. 


Running emerge compiled on Fri Oct 21 17:12:22 GMT 1994 

Consuming edif file gards/chip_euterpe . v2e 

Found edif structure: CHIP EUTERPE_4 6_V2 E 

Flattening edif; 

flattened 178 instances; created 145 nets in 

CHI P EUTERPE 4 6_V2 E 

Consuming power table information file gards/chip_euterpe . emerge . tab 
Performing Edif Transformations . . . 
Warning ! Port vddepl already top level . 
Warning! Port XRES_V already top level. 
Warning! Port XVDDA_V already top level. 
Warning! Port vddepO already top level. 
Warning! Port TCLK_ABD1PH already top level. 
Warning! Port vddts already top level. 
Warning! Port dinvrr2_abm already top level. 
Warning! Port dinvrrl_abm already top level. 
Warning! Port dinvrrO_abm already top level. 

Disgorging edif file gards/chip_euterpe . edif 

Writing edif structure: gards_4 7_chip_95_euterpe_4 6_edif Memory usage: 
Sat OCt 22 13:43:35 PDT 1994 

gmake [3] : *** No rule to make target -power . tab. local ' . Stop. 

rm chip_euterpe. v 

gmake[3] : Leaving directory 

VN/auspex/root/s41/euterpe-proteus/euterpe/verilog/bsrc 1 
gmake [2] : *** [chip_euterpegards . chip] Error 1 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Saturday, October 22, 1994 6:04 PM 
Vo@nosferatu' 

'geert@nosferatu'; 'tbr@nosferatu'; Vant@nosferatu'; 'hopper@nosferatu'; 'tom@nosferatu' 
euterpe build 


Euterpe releasebom is complete. With Tbr's help we realized that the last failure was due 
to the file rebuild not being present. So I felt comfortable that I wasn't going to 
clobber anything in /u/chip. 

I touch the file and started the s41 build. I have also chmoded such that you should be 
able to write there. 

I'll do another chmod as soon as the build has completed. 
It is running on rhodan with the output going into makerrs6 . 


Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Saturday, October 22, 1994 7:05 PM 
Vo@nosferatu' 

'geert@nosferatu'; 'hooper@nosferatu'; 'vant@nosferatu'; 'tbr@nosferatu'; 'tom@nosferatu' 
euterpe release and build 


Well the . checkoutrc of euterpe in /u/chip died at the same point as my local make - not 
having a rule to make power . tab . local . 

Now I tought that it was because I hadn't got rebuild but that didn't fix it, also /u/chip 
had one . 

Locally (/s41) I did gmake power . tab. local and it built just fine ?? 
maybe its something to do with the : : rule. 

Now the /s41 build is running gards . 


Lisa R. 
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Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope] 

Saturday, October 22, 1994 7:16 PM 

'Lisa Robinson' 

Vo@nosferatu'; 'geert@nosferatu'; 'tbr@nosferatu'; Vant@nosferatu'; 'hopper@nosferatu'; 


Subject: 


'tom@nosferatu' 
Re: euterpe build 


Lisa Robinson wrote 


>Euterpe releasebom is complete. With Tbr's help we realized that the 
>last failure was due to the file rebuild not being present. So I felt 
>comfortable that I wasn't going to clobber anything in /u/chip. 
> 

>l touch the file and started the s41 build. I have also chmoded such 
>that you should be able to write there . 

You should not have to do that . The chip_euterpegards . chip should create that file . Do 
you have an up to date bsrc/Makef ile . vo ? 


>I'll do another chmod as soon as the build has completed. 
>It is running on rhodan with the output going into makerrsS. 


> 


>Lisa R. 


> 


Tom Vo 


vo@microunity . com 


(408) 734-8100 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tom Vo [vo@merope] 

Saturday, October 22, 1994 7:17 PM 

'Lisa Robinson' 

Vo@nosferatu'; 'geert@nosferatu'; 'hooper@nosferatu'; 'vant@nosferatu'; 'tbr@nosferatu'; 

'tom@nosferatu' 

Re: euterpe release and build 


Lisa Robinson wrote .... 

> 

> 

> 

>Well the . checkoutrc of euterpe in /u/chip died at the same point as my 

>local make - not having a rule to make power . tab . local . 

> 

>Now I tought that it was because I hadn't got rebuild but that didn't 

>fix it, also /u/chip had one. 

> 

>Locally (/s41) I did gmake power . tab . local and it built just fine ?? 
>maybe its something to do with the : : rule . 

What ' s the : : rule ? 

> 

>Now the /s41 build is running gards . 


> 


>Lisa R. 


> 


Tom Vo 


vo®microunity . com 


(408) 734-8100 
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From: tbr 

Sent: Saturday, October 22, 1 994 7:22 PM 

To: Tom Vo' 

Cc: 'geerK^nosferatu'; 'hooper@nosferatu'; 'Lisa Robinson'; 'tom@nosferatu'; 'vant@nosferatu'; 

'vo@nosferatu' 

Subject: Re: euterpe release and build 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Vo wrote (on Sat Oct 22): 

Lisa Robinson wrote .... 

> 
> 
> 

>WeIl the .checkoutrc of euterpe in Ai/chip died at the same point as 
>my local make - not having a rule to make power. tab. local. 

> 

>Now I tought that it was because I hadn't got rebuild but that didn't 
>fix it, also /u/chip had one. 

> 

>Locally (/s41) I did gmake power.tab.local and it built just fine ?? 
>maybe its something to do with the :: rule. 

What's the:: rule? 

It's a hack. A :: rule is supposed to say that make should not even 
try to remake the thing on the right, but if the thing on eht left is 
out of date with respect to it, then execute the releated commands. 

The documentaton inditates you should not mix and : rules for the 
same target. I suspect this is the cause of the erratic behaviour. 
As far as I know, there is no clean way to get a "terminal" dependency 
(ie a dependency where it will not go trying to chain further). 


>Now the /s41 build is running gards. 

> 

>Lisa R. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@demeter] 
Saturday, October 22, 1994 7:22 PM 
Tom Vo' 

, geert@nosferatu'; 'hooper@nosferatu'; 'Lisa Robinson'; 'tom@nosferatu'; Vant@nosferatu'; 

Vo@nosferatu' 

Re: euterpe release and build 


Tom Vo wrote (on Sat Oct 22) : 
Lisa Robinson wrote .... 


>Well the . checkoutrc of euterpe in /u/chip died at the same point as 

>my local make - not having a rule to make power . tab . local . 

> 

>Now I tought that it was because I hadn't got rebuild but that didn't 
>fix it, also /u/chip had one- 
s' 

>Locally (/s41) I did gmake power . tab . local and it built just fine ?? 
>maybe its something to do with the : : rule . 

What 1 s the : : rule ? 

It's a hack. A :: rule is supposed to say that make should not even try to remake the 
thing on the right, but if the thing on eht left is out of date with respect to it, then 
execute the releated commands . 

The documentaton inditates you should not mix :: and : rules for the same target. I 
suspect this is the cause of the erratic behaviour. 

As far as I know, there is no clean way to get a "terminal" dependency (ie a dependency 
where it will not go trying to chain further) . 


>Now the /s41 build is running gards . 


> 


>Lisa R. 


> 


Tim 
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From: Tom Vo [vo@merope] 

Sent: Saturday, October 22, 1994 7:28 PM 

To: Tim B. Robinson' 

Cc: , geert@nosferatu'; 'hooper@nosferatu'; 'lisar@nosferatu'; 'tom@nosferatu'; Vant@nosferatu'; 

Vo@nosferatu' 
Subject: Re: euterpe release and build 


Tim B. Robinson wrote . . . . 


>Tom Vo wrote (on Sat Oct 22) : 


> What 1 s the : : rule ? 
> 

>It's a hack. A :: rule is supposed to say that make should not even 
>try to remake the thing on the right, but if the thing on eht left is 
>out of date with respect to it, then execute the releated commands. 
> 

>The documentaton inditates you should not mix : : and : rules for the 
>same target. I suspect this is the cause of the erratic behaviour. 
>As far as I know, there is no clean way to get a "terminal" dependency 
>(ie a dependency where it will not go trying to chain further) . 

OK . Learned something new today . 
I thought that it was just a typo . 

tvo 
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From: Tom Laidig [tom@clio] 

Sent: Saturday, October 22, 1 994 1 0:25 PM 

To: Tim B. Robinson' 

Subject: Re: mnemo and pandora 

Tim B. Robinson writes: 

t 

[Do you know if mail to these aliases ends up in a news group (like for 
jeuterpe)? (I'm not a news reader, so I'm not sure how to check). I 
jhad asked for it to be set up that way, but a glance at the 
jetc/aliases file leads me to suspect it may not be the case. If not, 
jean you get it fixed please? 

For mnemo checkins, I decided to reuse the muse.checkins.mnemosyne news 
group. 

The pandora checkins are going into muse.checkins.misc (as are a lot of 
other things — we haven't created any new groups for quite a while). 


Tom L 
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From: Tom Laidig [tom@clio3 

Sent: Saturday, October 22, 1994 1 1 :26 PM 

To: Tom Laidig' 

Cc: 'Guillermo A. Loyola'; Tim B. Robinson' 
Subject: Re: terp simulator for Creole tape 

Tom Laidig writes: 

I 

[Or perhaps a different question is in order: do we still maintain a 
Lterpsichore_ instruction level simulator? I don't think we should send 
|them a euterpe instruction level simulator — is that right, Tim? 

Oh, no, that doesn't make sense. We're sending them euterpe, after 
all, so the instruction-level simulator should go with it. Tim, I 
assume we'll have to send them mnemo in future tapes? I think I'll 
make the assumption for this tape that mnemo doesn't exist yet. 


00000 Ooooo 

(_)(_) 

1 ( Tom ) | 

<_J L (_) 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Saturday, October 22, 1 994 1 1 :50 PM 

To: Vo@nosferatu' 

Cc: 'hopper@nosferatu'; 'geert@nosferatu'; Vant@nosferatu'; 'tom@nosferatu'; 'tbr@nosferatu' 

Subject: euterpe build complete 


I believe that the build is complete. 
Lisa R. 
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From: Mark Hofmann [hopper@tomato] 

Sent: Sunday, October 23, 1 994 2:37 AM 

To: 'Lisa Robinson' 

Cc: Vo@nosferatu'; 'hopper@nosferatu'; , geert@nosferatu'; Vant@nosferatu'; , tom@nosferatu'; 

'tbr@nosferatu' 
Subject: Re: euterpe build complete 


Lisa Robinson writes: 

I believe that the build is complete. 
Well, I just watched the mail go by. Congratulations all! 
- hopper 
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From: Tom Laidig [tom@clio] 

Sent: Sunday, October 23, 1994 11:18 AM 

To: 'Lisa Robinson' 

Cc: Vo@nosferatu'; 'hopper@nosferatu'; 'geert@nosferatu*; Vant@nosferatiT; 'tom@nosferatu'; 

'tbr@nosferatu' 
Subject: Re: euterpe build complete 


Lisa Robinson writes: 
I 

| I believe that the build is complete. 
Wow ! Congratulat ions ! 


Tom L 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Sunday, October 23, 1 994 1 1 :39 AM 

To: 'hoppe^ambiorix'; 'lisa^ambiorix'; , tbr@ambiorix'; 'vanthof@ambiorix'; Vo@ambiorix' 
Subject: euterpe build 

Hi, 

Now that the build is complete , has someone already started up 
the DRC/LVS runs. I see a DRC in the queue but I think that is an 
older one. 

Geert 
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From: Tom Vo [vo@merope] 

Sent: Sunday, October 23, 1 994 1 1 :51 AM 

To: 'Mark Hofmann' 

Cc: 'lisar@nosferatu'; Vo@nosferatu'; 'hopper@nosferatu'; 'geert@nosferatu'; Vant@nosferatu'; 

'tom@nosferatu'; 'tbr@nosferatu' 
Subject: Re: euterpe build complete 


Mark Hofmann wrote .... 

>Lisa Robinson writes: 
> 

> I believe that the build is complete. 
> 

>Well, I just watched the mail go by. Congratulations all! 
> 

>- hopper 


This is a simple build folks . Save it for the real thing . 

The build should be OK for drc and short test . 

Its not quite ready for LVS because of unrouted nets . 

I can't tell what the fix should be with my home setup . 

tvo 
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From: vant [vanthof@hestia] 

Sent: Sunday, October 23, 1994 12:48 PM 

To: 'Geert Rosseel' 

Cc: 'hopper@ambiorix'; , lisar@ambiorix'; , tbr@ambiorix'; , vanthof@ambiorix'; 'vo@ambiorix' 

Subject: Re: euterpe build 


Geert Rosseel writes: 
> 

> Hi, 
> 

> Now that the build is complete , has someone already started up the 
>DRC/LVS runs. I see a DRC in the queue but I think that is an older 
>one . 

> 

> Geert 


Well, I just found out about the rebuild, so as of now, nope, no lvs/drc run has started 
on this rebuild. The one currently running is from Tom's last 

local build. Do you want me to trash the existing ones? 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! (tm) All kids love Log! #incluce 
<std_disclaim.h> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vant [vanthof@hestia] 

Sunday, October 23, 1994 1:12 PM 

"Geert Rosseel'; 'Lisa Robinson'; Tom Vo'; 'Mark Hofmann'; Tim B. Robinson' 
'Dave Van't Hof 

/u/chip/euterpe/... drc/lvs verification 


I was about ready to start up the lvs/drc of the latest euterpe build, but unfortunately, 
I'm unable to find the latest layouts in /u/chip. I am able to find them in the 
/n/auspex/s4l/ euterpe -snapshot tree. Is this going to be the final location for these 
layouts? 

I'll assume so and will run all verifications from there. I will kill any existing 
lvs/drc run on the previous run since we don't have enough licenses to have both running 
and time is important. 


Thanks, 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 


What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! ttincluce 
<std_disclaim . h> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vant [vanthof@hestia] 

Sunday, October 23, 1994 1:53 PM 

'Lisa Robinson'; 'Mark Hofmann'; 'Geert Rosseel'; Tom Vo'; Tim B. Robinson' 
'Dave Van't Hof 

nudder question on /n/auspex/s41/euterpe-snapshot 


I've started up the fullchip lower drc ' s and lvs/shorts check for the latest 
/n/auspex/ s41/euterpe- snap shot version of euterpe. 

I did notice that there is a proteus directory in the same location as euterpe on /s41, 
however, the euterpe/proteus link points off to a version of proteus on /n/auspex/s23/ . . . 

The version on /s23 is the most upto date version, so tiz a good thing the link points 
there . 

Are there plans to ever use the proteus version in /s41? 


Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 


What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! <tm) All kids love Log! #incluce 
<std_disclaim . h> 
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From: 


tbr 


Sent: 
To: 

Subject: 


Monday, October 24, 1994 9:18 AM 
Tom Laidig' 

Re: mnemo and pandora 


Follow Up Flag: Follow up 
Flag Status: Red 


Tom Laidig wrote (on Sat Oct 22): 

Tim B. Robinson writes: 

I 

[Do you know if mail to these aliases ends up in a news group (like for 
jeuterpe)? (I'm not a news reader, so I'm not sure how to check). I 
[had asked for it to be set up that way, but a glance at the 
jetc/aliases file leads me to suspect it may not be the case. If not, 
jean you get it fixed please? 

For mnemo checkins, I decided to reuse the muse.checkins.mnemosyne news 
group. 

The pandora checkins are going into muse.checkins.misc (as are a lot of 
other things -- we haven't created any new groups for quite a while). 

Actually, I wasn't referring to the checkins. If I under stand it 
correctly, 'mail euterpe' results in something permanently logged in 
muse.euterpe or some such. That's what I'd like to be happening for 
the mnemo and pandora aliases. I'd asked ken to set it up that way, 
but I wasn't sure if it had happened. 


Tim 
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To: 


From: 


Sent: 


Subject: 


Cc: 


tbr 

Monday, October 24, 1994 9:21 AM 
Tom Laidig' 

'Guillermo A. Loyola'; Thomas Laidig' 
terp simulator for creole tape 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Sat Oct 22): 

I dunno if you're the right person for this... if not, could you forward 
please? 

One of the things that we put on our quarterly creole tape is the 
terpsichore instruction- level simulator. I used to get this by doing 

cvs co terp-sim 

cd osfl/src/usr/ccs/bin 

mv gas/terp-opcode.h . 

rm -rf gas 

mkdir gas 

mv terp-opcode.h gas 

I believe this was designed to set things up so they could make the 
simulator, but so they wouldn't get the assembler or anything else. 
Anyway, I now get 

cvs co terp-sim 

cvs checkout: cannot find module ^osfl/src/usr/ccs/bin/sim' - ignored 
cvs checkout: cannot find module ^osfl/src/usr/ccs/bin/gas' - ignored 

Could you tell me what I should now be doing? 


Or perhaps a different question is in order: do we still maintain a 
_terpsichore_ instruction level simulator? I don't think we should send 
them a euterpe instruction level simulator - is that right, Tim? 

I believe we should be sending them the euterpe one (and indeed 
everything on the hardware side related to euterpe). We have 
obligations to provide them with databases relating to an 
implementation of the terpsichore architecture (which euterpe is 
supposed to be). 


Tim 
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Sent: 


To: 


Subject: 


From: 


Cc: 


tbr 

Monday, October 24, 1994 9:22 AM 
Tom Laidig' 

'Guillermo A. Loyola'; Tom Laidig' 
Re: terp simulator for Creole tape 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Sat Oct 22): 

Tom Laidig writes: 

i 

|Or perhaps a different question is in order: do we still maintain a 

| _terpsichore_ instruction level simulator? I don't think we should send 

jthem a euterpe instruction level simulator - is that right, Tim? 

Oh, no, that doesn't make sense. We're sending them euterpe, after 
all, so the instruction-level simulator should go with it. Tim, I 
assume we'll have to send them mnemo in future tapes? I think I'll 
make the assumption for this tape that mnemo doesn't exist yet. 

Yes, I think we will, but I agress we can skip it for this round. 


Tim 
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From: 


tbr 


Sent: 
To: 

Subject: 


Monday, October 24, 1994 10:38 AM 
'lisar' 

euterpe array timing checks 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark discovered a case last week when looking at something else, where 
there was a timing error in the handling of one of the arrays. Unit 
delay simulation was not showing it. We need to figure out how to 
make checking for this bullet proof. I think it's a far more 
complicated problem than we had on calliope because there are lot's of 
different ways the arrays can be accessed. Maybe we need to dust off 
the assertion checking stuff on the Zycad? 


Tim 
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From: Mark Hofmann [hopper@pelorus] 
Sent: Monday, October 24, 1 994 1 0:47 AM 
To: 'Tim B. Robinson' 
Subject: Re: startjicense 

Tim B. Robinson writes: 


Where does it live? I don't see it in my path. 
/a/license/bin/start_license. 

Also here is a comre complete compilation of tools that I am working on: 


Tool 

Vendor 

Demon licensed nodes 

allegro 

cadence 

rhea floats 

caeviews 

cadence 

rhea floats 

concept 

cadence 

rhea floats 

ged 

cadence 

rhea floats 

packager 

cadence 

rhea floats 

verilog 

cadence 

rhea floats 

compile 

cadence 

rhea floats 

xvlsi 

compass 

none abderus euterpe kephalos millennium 



poseidon ambiorix athena 

dracula 

special 

none tomato cyclops medusa mothra 

cadence 


hyperplot 

none 

godzilla 

veri check 

iss 

hestia 

gards 

silvar-lisco 

floats 

pcomp 

silvar-lisco 

floats 

redit 

silvar-lisco 

floats 

garout 

silver-lisco 

floats 

gplace 

silver-lisco 

floats 

undertow 

veritools 

floats 


hspice meta- software ambiorix ares boa frodo hera kephalos mercury 
merope narcissus pegasus pelorus phobos 
polyhymnia psyche thalia 

gsi meta- software floats 

xpcad pcad floats 

vxi zycad nosferatu aphrodite 

virsim zycad floats 

energize lucid floats 
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From: Tom Vo [vo@merope] 

Sent: Monday, October 24, 1994 12:26 PM 

To: 'Lisa Robinson'; Tim B. Robinson'; 'Geert Rosseel'; 'Mark Hofmann'; 'Dave Van't Hof ; 

Thomas Laidig' 
Subject: euterpe top level route 


We had several unrouted nets with the simple euterpe that lisar built over the weekend 
There' re a few things that warrant further investigations : 

1. The file order . sub. nets did not map to anything in the GARDS dbase . 

2. The last few lines in the routing strategy , toplevel.rcf got 
commented out . 


! Now try everything in METAL3 /METAL4 

control: netlist=ordered. all .nets; f {netf lag) =-1 ; passes=2; 

linesearch: searchdepth = 6; f irst_layer=2 ; best = 10; pinpair limit = -3; xlslimit = -1; 
linesearch: searchdepth = 40; f irst_layer=2 ; best = 10; pinpairlimit = -3;xlslimit = -1; 

! Try maze route on METAL3 /METAL4 only 

Imaze: mazebox = 999; xmazelimit = 0; ymazelimit - 0; first = 2; last =3; ! Now give it 
2/3/4 

Smaze: mazebox = 999; xmazelimit = 0; ymazelimit = 0; first = 1; last = 3; 


tvo 
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From: Mark Hofmann [hopper@pelorus] 
Sent: Monday, October 24, 1994 3:07 PM 
To: , cadettes@pelorus' 
Cc: Tim B. Robinson' 
Subject: CAD tools license & info file 


Hi, 

I've made another pass at gathering data on where the licensing information 
for many of our CAD tools lives. What I'm intersted in being able to do 
is have sysadm help when a user says "I can't run <foobar> on my workstation". 
<foobar> is likely the command name that the user typed (not necessarily 
the name of the binary or the name that appears in a license file). At any 
rate, could y'all please fill in any glaring errors or gaping holes? 

I'll collate and pass on to the sysadms. In fact, where would be a good 
place to keep this file so that we can periodically update it? 


-thanks, 
hopper 


Tool 

Vendor 

Demon licensed nodes (arch) 

xpcad 

altium 

rhea floats (sun) 

gerberview 

altium 

rama floats (sun) 

allegro 

cadence 

rhea floats (sun, hp) 

caeviews 

cadence 

rhea floats (sun, hp) 

compile 

cadence 

rhea floats (sun, hp) 

concept 

cadence 

rhea floats (sun, hp) 

ged 

packager 

cadence 

rhea floats (sun) 

cadence 

rhea floats (sun, hp) 

verilog 

cadence 

rhea floats (sun, hp) 

v2e 

cadence 

none aphrodite (sun) 

dracula 

cadence 

on node tomato eye lops medusa mothra (sun) 

xvlsi 

compass 

none abderus euterpe kephalos millennium 



poseidon ambiorix athena (sun) 

vericheck 

iss 

hestia tomato cyclops medusa mothra (sun) 

energize 

lucid 

rhea floats (sun) 


hspice m eta-software rhea ambiorix ares boa frodo hera kephalos 
mercury merope narcissus pegasus 
pelorus phobos poly hymn ia psyche thalia 

gsi meta-software rhea floats (sun, hp) 

hyperplot pinebush none godzilla (sun) 

capclc silver-lisco godzilla floats (sun) 
garout silver-lisco godzilla floats (sun) 
gplace silver-lisco godzilla floats (sun) 
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maskout silvar-Iisco godzilla floats (sun) 

pcomp silvar-lisco godzilla floats (sun) 

pgroute silvar-lisco godzilla floats (sun) 

redit silvar-lisco godzilla floats (sun) 

rdump silvar-lisco godzilla floats (sun) 

rload silvar-lisco godzilla floats (sun) 

slnet silvar-lisco godzilla floats (sun) 

undertow veritools rhea floats (sun) 

edif22mif zycad none nosferatu aphrodite (sun) 

linkmm zycad none nosferatu aphrodite (sun) 

vxi zycad rhea nosferatu aphrodite (sun) 

virsim zycad rhea floats 


Vendor - License file Index: 

Vendor: altium, tool: gerberview 
License binary: /n/auspex/s34/ecam 
License file: /n/auspex/s34/ecam/license.dat 

Vendor: altium 

License binary: /a/pcad/license/bin.sun4 
License file: /a/pcad/license/pcadlic.dat 

Vendor: cadence 

License binary: /a/cadence/tools/bin 

License file: /a/cadence/share/license/license.55000dbe 

Vendor: cadence, tool: dracula 

License binary: /a/dracula4.1 /tools/bin 

License file: /a/dracula4.1/share/license/license.55409301 

Vendor: lucid 

License binary: /sl/energize2.1/flexlm/bin ??? 
License file: /sl/energize2.1/flexlm/etc/l icense.dat ??? 

Vendor: silvar-lisco 

License binary: /a/silvar-lisco/license 

License file: /a/silvar-lisco/license/license.dat 

Vendor: sun, tool: fortran compiler 

License binary: /n/auspex/s34/fortran/license/bin4 

License file: /n/auspex/s34/fortran/license/bin4/license.dat 

Vendor: veritools 

License binary: /a/veritools/Lic.Mgr+typetool/license 
License file: /a/license/license. undertow 

Vendor: zycad 

License binary: /a/vxi/vxi_l.l/Iicense 

License file: /a/license/license. vxi. 1.1. combined 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Monday, October 24, 1 994 5:23 PM 
To: Tim B. Robinson' 
Subject: Re: pandora newsgroup 

Tim B. Robinson wrote: 

> 
> 
> 

> When ken set up the mail alias "pandora" it was supposed to get copied 

> to a news group like the "euterpe" alias is. Apparantly, this is not 

> happening. Can you check it please? 

i don't think the mail we got mentioned gatewaying the mail alias to 
the newsgroup. 

i've now set it up to go both ways. 


ericm ericm@microunity.com 
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Sent: 


From: 


tbr 

Monday, October 24, 1994 5:56 PM 


To: 


Subject: 


'ericm' 

pandora newsgroup 


Follow Up Flag: Follow up 
Flag Status: Red 


When ken set up the mail alias "pandora" it was supposed to get copied 
to a news group like the "euterpe" alias is. Apparantly, this is not 
happening. Can you check it please? 


Tim 
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From: tbr 

Sent: Monday, October 24, 1994 7:04 PM 

To: 'Eric Murray' 

Subject: Re: pandora newsgroup 

Follow Up Flag: Follow up 

Flag Status: Red 


Eric Murray wrote (on Mon Oct 24): 

Tim B. Robinson wrote: 

> 
> 
> 

> When ken set up the mail alias "pandora" it was supposed to get copied 

> to a news group like the "euterpe" alias is. Apparantly, this is not 

> happening. Can you check it please? 

i don't think the mail we got mentioned gateway ing the mail alias to 
the newsgroup. 

i've now set it up to go both ways. 
Thanks. Actually it did mention it, but perhaps not clearly: 
tbr wrote (on Thu Oct 20): 


Please create a new mail alias and connect it to a news group 
called "pandora" for our new workstation program. 

Please put the following in initially and I'll send out mail inviting 
other people to join in. 

gmo 

abbott 

vandyke 

tbr 

craig 

mouss 

woody 

age 

geert 

lisar 
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Sent: 


From: 


tbr 

Monday, October 24, 1994 7:39 PM 


To: 


Cc: 


'solo' 
'age' 


Subject: 


PCI bus clocking. 


Follow Up Flag: Follow up 
Flag Status: Red 

In the pandora system we will have to figure out how to get both 
Mnemosynes on the PCI bus to be in the same clock domain. One way is 
to get the 54Mz reference the Pandora Euterpe needs from the Hermes 
expansion connector out of Hestia. However, we also want Pandora to 
work stand alone, which suggests is will have to have it's own 
oscillator. We might have to consider some kind of swicthing 
according to whether Hestia is there or not. 

Even with the common reference we will have to deal with arbitrary 
phase differences. Without it I assume we have to have some kind of 
synchronizer operating at the order of the PCI clock rate. My reading 
of the spec says that frequency can be anything less than 33MHz, but I 
assume we would want to run it close to the max. If so, what's your 
estimate of synchronizer failure rate? 


Tim 
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From: 


tbr 


Subject: 


Sent: 
To: 


Cc: 


Monday, October 24, 1994 7:45 PM 
'Geert Rosseel' 

'bpw@ambiorix'; 'solo@ambk>rix'; 'stick@ambiorix' 
Planning, schedule , etc ... 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Oct 15): 

2. A stronger TTL DRAM I/O driver / Mnemo has to drive a 
lot more memory than Euterpe. 

3. A PCI bus driver ... Alan has a description of the specs 
of that driver ... 

I think we need to sit down and thrash out how we are going to handle 
5V again. There is no point making a mongo ttl driver for the DRAMs 
if we have to buffer it outside anyway to handle the 5 V. 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 24, 1994 7:45 PM 
'Geert Rosseel' 

'bpw@ambiorix'; 'solotgambiorix'; 'stick@ambiorix' 
Planning, schedule , etc ... 


Geert Rosseel wrote (on Sat Oct 15) : 

2 . A stronger TTL DRAM I/O driver / Mnemo has to drive a 
lot more memory than Euterpe . 

3 . A PCI bus driver . . . Alan has a description of the specs 
of that driver . . . 

I think we need to sit down and thrash out how we are going to handle 5V again. There is 
no point making a mongo ttl driver for the drams if we have to buffer it outside anyway to 
handle the 5V. 


Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Monday, October 24, 1994 8:45 PM 
'Curtis Abbott' 

MediaCom software presentation 


Follow Up Flag: Follow up 
Flag Status: Red 

Curtis Abbott wrote (on Mon Oct 17); 

This Friday, Oct 21 at 2:00, there will be a presentation in the War 
Room about MediaCom software. We will try to summarize the way we're 
organizing the software, tell where we stand on a number of specific 
tasks that we've been working on, and draw out the lessons we think 
are important about using Euterpe to run DSP-intensive, real-time 
algorithms. 

Sorry I had to miss the second half of this. Let me know if there 
were significant conclusions I should have heard . . . 


Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Tuesday, October 25, 1 994 12:53 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 59.0 initiated by woody completed @ Mon Oct 24 
22:52:27 PDT 1994 with exit status 0.. chip 
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From: Jay Tomlinson [woody@luckboy] 

Sent: Tuesday, October 25, 1994 9:39 AM 

To: 'geert@luckboy' 

Subject: he build failed, there was a problem connecting to clio 


Geert , 
FYI: 

Buffalo Chip wrote (on Mon Oct 24) : 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

=> Xlib: connection to "clio: 0.0" refused by server 
Xlib: Client is not authorized to connect to Server 
Test: Error in opening display = clio : 0.0 
GARDS G PLACE 7.126 -- General Placer 

Copyright (c) 1994 SILVAR-LISCO. All rights reserved. 
Design: hcO-passl Started at; 94/10/24 22:39:08 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components . . . 

Loading nets. . . 

Loading logical types . . . 

Processing physical types... 

Loading cell_types. . . 

Creating net-comp xref table... 

gmake[2]: *** [gards/hcO-passl . nof ] Error 1 

gmake [2]: Leaving directory 
VN/auspex/root/slO/chip/euterpe/verilog/bsrc/hc ' 

gmake[l]: *** [hcO-base . short . nets] Error 1 

rm hc_sid. optesp hc_sid.esp 

gmake [1] : Leaving directory 
VN/auspex/root/slO/chip/euterpe/verilog/bsrc/hc ' 

gmake: *** [hcOgards] Error 1 

gmake: "gards/hcO . obs • is up to date. 

# 

# turn off pgr out e 
# 

[ -f gards/nopgroute ] j | touch gards/nopgroute 
# 

# use padtiles 
# 

[ -f gards/usepadtiles ] | | touch gards/usepadtiles 
# 

# use pifpack 
# 

[ -f gards/usepifpack ] | | touch gards/usepifpack 
# 

# insert an instance of the clock tree 
# 

[ -f gards/addclock ] | | touch gards/addclock 
# 

# disable old dcell placement obstruction 
# 

[ -f gards/noobs ] | ] touch gards/noobs 
# 

# now do it . . . 
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# 

gmake GARDS_DISPLAY=clio : 0 . 0 gards/hcl- iter 
gmake [1] : Entering directory 
VN/auspex/root/slO/chip/euterpe/verilog/bsrc/hc ' 
# 

# Take a snooze to make sure vfiles looks older than the .v2e file 

# when they are on different NFS file systems 
# 

sleep 10 

CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/sl0/chip/euterpe/tools/bin/v2e -host cyclops -f vfiles -o gards/hcl .v2e -c 
gards/hcl .v2e. config -1 gards/hcl .v2e . log -y . . /io -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/mlib +libext+.v -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/dxlib -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/dclib -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/delib 

V2E 1.0a Oct 24, 1994 22:43:21 

* Copyright Cadence Design Systems Inc. 1990. * 

* All Rights Reserved. Licensed Software. * 

* Confidential and proprietary information which is the * 

* property of Cadence Design Systems Inc. * 
Compiling source file "hc.v M 

Compiling source file "hc_tagmatch. v" 

Compiling source file "hc_cmp6.v" 

Compiling source file "hc_fifo8.v" 

Compiling source file "hc_buf_8.v" 

Compiling source file "hc_ostate.v" 

Compiling source file "hc_prbctrl . v" 

Compiling source file "hc_sdecode . v" 

Compiling source file "hc_txcrc . v" 

Compiling source file "hc_sid.v" 

Compiling source file "hc_parse . v" 

Compiling source file "hc_rxcrc . v" 

Compiling source file "hc_f if o8ctrl . v" 

Compiling source file "hc_error . v" 

Scanning library directory "../io" 

Scanning library directory 
"/n/auspex/slO/chip/euterpe/proteus/verilog/mlib" 

Scanning library directory 
" /n/auspex/slO/chip/euterpe/proteus/verilog/dxlib" 

Scanning library directory 
"/n/auspex/slO/chip/euterpe/proteus/verilog/dclib" 

Warning: library directory 
"/n/auspex/slO/chip/euterpe/proteus/verilog/delib" was specified but not needed. 

Highest level modules: 

he 

Reading configuration file gards/hcl .v2e . config .... 
Processing configuration file .... 
Translating Verilog source .... 
Writing output to gards/hcl . v2e .... 
0 warnings 0 errors 

End of V2E 1.0a Oct 24, 1994 22:44:09 

CHIPROOT=/n/auspex/slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/emerge -f -R -p gards/hcl . emerge . tab -e gards/hcl .v2e 
-o gards/hcl. edif -O gards/hcl . emerge . log -I . . /cg/cgclockbias . v2e cgclockbias 

Running emerge compiled on Fri Oct 21 17:12:22 GMT 1994 

Consuming edif file gards/hcl . v2e 

Found edif structure: HC1_46_V2E 
Flattening edif; 

flattened 1121 instances; created 1509 nets in HC1_46_V2E 

Reading Edif file for instance placement: . . /cg/cgclockbias .v2e 
Consuming power table information file gards/hcl . emerge . tab 
Performing Edif Transformations. . . 
Warning! Port PHI_A2P already top level. 
Warning! Port PHI_B2P already top level. 
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Disgorging edif file gards/hcl . edif 

Writing edif structure: gards_4 7_hcl_46_edif 
Memory usage: 7.17 6MB 

/usr/local/bin/perl genpiml.pl > pim.tmp 

mv pim.tmp gards/hcl-passl .pirn 

# 

# Get an initial sdl file. A manhattan approximation will be used 
# 

gmake GARDS_DISPLAY=clio: 0 . 0 CYCLETIME=895 gards/hcl -pass 2 . sdl 

gmake[2] : Entering directory 
* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc ' 

cp power . tab . local gards/hcl .power . tab . local 

CHIPROOT=/n/auspex/ si 0 / chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/topt -p 

/n/auspex/slO/chip/euterpe/proteus/misc/power . tab -p gards/hcl .power . tab . local \ 

-h /n/auspex/slO/chip/euterpe/proteus/leafgen/dcload/dcload. lib 
-h /n/auspex/slO/chip/euterpe/proteus/exlax/dcload/dcload. lib -h 
/n/auspex/slO/chip/euterpe/proteus/custom/dcload/dcload. lib \ 

-g /n/auspex/slO/chip/euterpe/proteus/leafgen/toptList -g 
/n/auspex/slO/chip/euterpe/proteus/exlax/toptList -g 
/n/auspex/slO/chip/euterpe/proteus/custom/ toptList \ 

-A /n/auspex/slO/chip/euterpe/proteus/leaf gen/caps/cap . lib -A 
/n/auspex/slO/chip/euterpe/proteus/exlax/caps/cap . lib -A 
/n/auspex/slO/chip/euterpe/proteus/custom/caps/cap . lib \ 

-H /n/auspex/slO/chip/euterpe/proteus/leaf gen/time/tim. lib -H 
/n/auspex/slO/chip/euterpe/proteus/custom/ time/tim. lib -H 
/n/auspex/slO/chip/euterpe/proteus/exlax/time/tim . lib \ 

-1 895 \ 

-e gards/hcl .edif \ 

-k gards/hcl-passl . strength \ 

-B gards/hcl-passl . sdl \ 

-s gards/hcl-passl . stat \ 

-O gards/hcl-passl . topt . log \ 

-z 2 -M mobimos -R -t 50 -b 10 -a 24 - 0 - F 

Running topt (Timing OPTimizer) compiled on Fri Oct 21 23:31:27 GMT 
1994 

Processing a: Mobimos, Flop/Latch design 
Consuming edif file gards/hcl . edif 

Found edif structure: gards_4 7_hcl_4 6_edif 
Flattening edif; 

HC already flat. 

found 1122 instances; found 2851 nets in gards_47_hcl_4 6_edif 
Consuming power table information file 
/n/auspex/slO/chip/euterpe/proteus/misc/power . tab 

Consuming power table information file gards/hcl. power. tab. local 

Reading Stats file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/stats . eel 

Reading Stats file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/stats . cmos 

Reading Stats file 
/n/auspex/slO/chip/euterpe/proteus/exlax/stats . ea 

Reading Stats file 
/n/auspex/slO/chip/euterpe/proteus/custom/stats . eel 

Reading Legal Cell List file 
/n/auspex/slO/chip/euterpe/proteus/leafgen/toptList 

Reading Legal Cell List file 
/n/auspex/slO/chip/euterpe/proteus/exlax/toptList 

Reading Legal Cell List file 
/n/auspex/slO/chip/euterpe/proteus/custom/toptList 

Performing Edif Transformations... 

Reading DC Loads file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/dcload/dcload. lib 

Reading DC Loads file 
/n/auspex/slO/chip/ euterpe/proteus/exlax/dcload/ dcload . lib 

Reading DC Loads file 
/n/auspex/slO/chip/euterpe/proteus/custom/dcload/dcload . lib 
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Reading pin cap values from 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/caps/cap . lib 

Reading pin cap values from 
/n/auspex/slO/chip/euterpe/proteus/exlax/caps/ cap . lib 

Reading pin cap values from 
/n/auspex/slO/chip/euterpe/proteus/custom/caps/cap . lib 
Status information in gards/hcl-passl . stat 
Warning! Cell cgclockbias not on legal cell list. 

Any gate in it's path is not AC power optimized 
No swing calculations will be performed 
Pruning flattened network of unused instances... 31 pruned in 2 

passes . 

Checking/Setting swing values. . . 

Found 19 Warnings! Please check stat file! 

Reading Cap/Delay table file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/time/tim . lib 

Reading Cap/Delay table file 
/n/auspex/slO/chip/euterpe/proteus/custom/time/tim. lib 

Warning! Cell cache at line 4 is not in legal cell list 
Warning! Cell cahalf at line 10 is not in legal cell list 
Warning! Cell cr at line 13 is not in legal cell list 
Warning! Cell ctag at line 20 is not in legal cell list 
Warning! Cell gtlb at line 23 is not in legal cell list 
Warning! Cell sccgbfrO at line 52 is not in legal cell list 
Warning! Cell sccgdr at line 94 is not in legal cell list 
Reading Cap/Delay table file 
/n/auspex/slO/chip/euterpe/proteus/exlax/time/tim, lib 

Connecting floating differential inputs to net vref_0ph. . . 
Connected 0 inputs to net vref_0ph. . . 

DC Load checks only for cell(s): 

eawwlvref 56s7x4a eawwlvref 20sl0xla eawwlvref I6s2x4a xbc01df32s 
xbc01df24s xbcOldflSs xbc01dfl2s xbc01df8s xbc01df6s xbc01df4s 
xbc01df2s xbcOl xbcmos2ecldf 16s xbcmos2ecldf 12s xbcmos2ecldf 8s 
xbcmos2ecldf 4s xbcmos2ecldf 2s xbcmos2ecl 


DC Load checks only for inst(s) : 

Usidactive/uO Uscmderr/uO Uscrcerr/uO rawdh/uO rawdh/ul 

rawdh/u2 

rawdh/u3 rawdh/u4 rawdh/u5 rawdh/u6 rawdh/u7 rawdl/uO rawdl/ul 
rawdl/u2 rawdl/u3 rawdl/u4 rawdl/u5 rawdl/u6 rawdl/u7 


Force swing levels for inst(s): 


Warning ! 

No 

Warning ! 

No 

Warning ! 

No 

Warning! 

No 

Warning ! 

NO 

Warning ! 

No 

Warning ! 

No 

Warning ! 

NO 

Warning! 

No 

Warning! 

No 

Warning! 

NO 

Warning ! 

NO 

Warning ! 

No 

Warning! 

No 

Warning! 

NO 

Warning ! 

No 

Warning ! 

No 

Warning ! 

No 

Warning J 

NO 

Warning ! 

No 

Warning ! 

No 


CKFI_AD1PH pin 
CKFI_BD1PH pin 
CKRI_AD1PH pin 
CKRI_BD1PH pin 
CLR_ABM<8> pin 
CLR_ABM<7> pin 
CLR_ABM<6> pin 
CLR_ABM<5> pin 
CLR_ABM<4> pin 
CLR_ABM<3> pin 
CLR_ABM<2> pin 
CLR_ABM<1> pin 
CLR_ABM<0> pin 
PHI_ANM<8> pin 
PHI_ANM<7> pin 
PHI_ANM<6> pin 
PHI_ANM<5> pin 
PHI_ANM<4> pin 
PHI_ANM<3> pin 
PHI_ANM<2> pin 
PHI_ANM<1> pin 


capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 
capacitance data 


for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
for cgclockbias 
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Warning! No PHI_ANM<0> pin capacitance data for cgclockbias 

Warning! No PHI_ENM<8> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<7> pin capacitance data for cgclockbias 

Warning! No PHI_ENM<6> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<5> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<4> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<3> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<2> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<1> pin capacitance data for cgclockbias 

Warning! No PHI_BNM<0> pin capacitance data for cgclockbias 

Warning! No RD_BM<8> pin capacitance data for cgclockbias 

Warning! No RD_BM<7> pin capacitance data for cgclockbias 

Warning! No RD_BM<6> pin capacitance data for cgclockbias 

Warning! No RD_BM<5> pin capacitance data for cgclockbias 

Warning! No RD_BM<4> pin capacitance data for cgclockbias 

Warning! No RD_BM<3> pin capacitance data for cgclockbias 

Warning! No RD_BM<2> pin capacitance data for cgclockbias 

Warning! No RD_BM<1> pin capacitance data for cgclockbias 

Warning! No RD_BM<0> pin capacitance data for cgclockbias 

Warning! No SI_AM<8> pin capacitance data for cgclockbias 

Warning! No SI_AM<7> pin capacitance data for cgclockbias 

Warning! No SI_AM<6> pin capacitance data for cgclockbias 

Warning! No SI_AM<5> pin capacitance data for cgclockbias 

Warning! No SI _AM<4> pin capacitance data for cgclockbias 

Warning! No SI_AM<3> pin capacitance data for cgclockbias 

Warning! No SI_AM<2> pin capacitance data for cgclockbias 

Warning! No SI_AM<1> pin capacitance data for cgclockbias 

Warning! No SI_AM<0> pin capacitance data for cgclockbias 

Warning! No VFFMAX pin capacitance data for cgclockbias 

Warning! No vffmin pin capacitance data for cgclockbias 

Warning! No VFFNOM pin capacitance data for cgclockbias 

Warning! No VFFREFMAX pin capacitance data for cgclockbias 

Warning! No VFFREFMIN pin capacitance data for cgclockbias 

Warning! No VFFREFNOM pin capacitance data for cgclockbias 

Warning! No VFFREFVAR pin capacitance data for cgclockbias 

Warning! No VFFVAR pin capacitance data for cgclockbias 

Warning! No VRRG<2> pin capacitance data for cgclockbias 

Warning! No VRRG<1> pin capacitance data for cgclockbias 

Warning! No VRRG<0> pin capacitance data for cgclockbias 

Warning! No XFER__BM<8> pin capacitance data for cgclockbias 

Warning! No XFER_BM<7> pin capacitance data for cgclockbias 

Warning! No XFER_BM<6> pin capacitance data for cgclockbias 

Warning! No XFER_JBM<5> pin capacitance data for cgclockbias 

Warning! No XFER_BM<4> pin capacitance data for cgclockbias 

Warning! No XFER_BM<3> pin capacitance data for cgclockbias 

Warning! No XFER_BM<2> pin capacitance data for cgclockbias 

Warning! No XFER_BM<1> pin capacitance data for cgclockbias 

Warning! No XFER_BM<0> pin capacitance data for cgclockbias 

Ignoring these nets: 

PHI_B2P PHI_A2P vref_Oph 


Optimizing power. . . 
Iteration: 1 

Path power optimizer 

ERROR! 1 path exceeded cycle time. Check status file. 
DC Load Calculations 

Unpowered Instance check: 2 found. 

Iteration: 2 

Path power optimizer 

IntrinsicWarning: Warning! No clk_to_q gate fanin 1 delay for gate xbcmos2ecldf 2s for 
input pin CIN_ABM 

ERROR! 2 paths exceeded cycle time. Check status file. 
DC Load Calculations 

Unpowered Instance check: 1 found. 

Iteration: 3 

Path power optimizer 

ERROR! 2 paths exceeded cycle time. Check status file. 
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DC Load Calculations 
Unpowered Instance check: 


1 found. 


Squeezing out extra time in paths. 
Iteration: 4 

Path power optimizer 

ERROR! 1 path exceeded cycle time. Check status file. 
DC Load Calculations 

Unpowered Instance check: 1 found. 

Iteration: 5 

Path power optimizer 

ERROR! 2 paths exceeded cycle time. Check status file. 
DC Load Calculations 

Unpowered Instance check: 1 found. 

Iteration: 6 

Path power optimizer 

ERROR! 2 paths exceeded cycle time. Check status file. 
DC Load Calculations 

Unpowered Instance check: 1 found. 

Savings by squeezing out extra time = (6682 - 6572) = 1.65% 
Change from original input power = (6572 - 158) = 97.60% 

Warning! 1 unpowered or untouched instances. 

Warning! There are under powered instances. 

NOTE: 697 unpowered nets. 

NOTE: 46 nets with delays less than 50.00ps 
NOTE: Power levels changed for 1059 instances. 


Atoms: count atom bjt isrc pld clock 

BJT Totals: 1091 9414 19517 14160 13396 6759 

Generating instance drive strength file gards/hcl-passl . strength 
Disgorging sdl file gards/hcl-passl . sdl 

Writing sdl structure: gards_47_hcl_4 6_edif 
Memory usage: 2 6.7 54MB 

Exit code would be 2 (Failed Max Timing) , but is forced to 0 
CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/pdlcat -p 

/n/auspex/slO/chip/euterpe/clockbias : /n/auspex/slO/chip/euterpe/gards/subb 
locks : /n/auspex/slO/chip/euterpe/gards/dcell : /n/auspex/ slO/chip/euterpe/pr 
oteus/gards/leaf : /n/auspex/slO/chip/euterpe/proteus/gards/sof a : /n/auspex/s 

10/chip/euterpe/proteus/gards/dcell ""grep -v < gards/hcl-passl . strength j awk '{print 

$4;}' | \ 

sort | uniq | awk ' {printf ("%s.pdl $1)}'" > gards/hcl-passl . macros . temp 
mv gards/hcl -passl. macros . temp gards/hcl-passlmacros .pdl 
**** SLNET hcl-passl 
Mon Oct 24 22:47:07 PDT 1994 

sed -e 1 s ! DESIGN_NAME ! hcl-passl ! ' -e " s ! EDIF_FILE ! he 1 -passl . sdl ! ■ \ 

-e 1 s'CHIPROOT! /n/auspex/slO/chip/euterpe! ' -e ' s ! TECH_GPLACE ! hcl- 
passl . gplace .mobi234 ! ' \ 

-e 1 sJTECH_REDIT! hcl-passl. redit ,mobi234 ! ' \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/hcl-passl .vrf 
echo "cd "abspath" /gards; \ 

echo translate_all | HOME=/n/auspex/sl0/chip/euterpe/ tools 
LM_LICENSE_FlLE=/n/auspex/slO/chip/euterpe/tools/sl/license/lxcense. dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT* /n/auspex/ slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/net/dir/slnet hcl-passl" | /usr/local/bin/rexec 
cyclops sh 

** SLNET 1.037 ** SL_NET VI. 000 -- Net list Manipulator 
Copyright (c) 1993,1994 SILVAR-LISCO . All rights reserved. 
Design: hcl-passl Started at: 94/10/24 22:47:09 
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Loading file "hcl-passl . sdl" . 
[XBC01DF16S] 
[XBC01DP4S] 
[XBC01DF8S] 
[XBCMOS2 ECLDF2 S ] 
[XBBUFDF16S] 
[XBFFDH6S] 
[XBFFDF24S] 
[XBFFDF32S] 
[XBFFDH12S] 
[XBFFDH24S] 
[XBFFDH3S] 
[XBFFBDH12S] 
[XBFFDF6S] 
[XBFFDF12S] 
[XBFFBDF3 2S] 
[XBFFDF16S] 
[XBFFDH2S] 
[XBFFDF2S] 
[XBFFDF4S] 
[XBFFDF8S] 
[XBOR3DF6S] 
[XBOR3DF8S] 
[XBOR3DF12S] 
[XBOR3DF2S] 
[XBOR3DF4S] 
[XBOR14DF8S] 
[XBORFF5DF2 4 S ] 
[XBORFF5DH6S] 
[XBORFF5DH12S] 
[XBORFFB5DF32S] 
[XBORFF5DF4S] 
[XBORFF5DF12S] 
[XBORFF2DH8S] 
[XBORFF2DF2S] 
[XBORFF2DF24S] 
[XBORFF2DH6S] 
[XBORFF2DH16S] 
[XBORFF2DH24S] 
[XBORFF2DF12S] 
[XBORFFB2DF4S] 
[XBORFF2DF4S] 
[XBORFF2DF6S] 
[XBORFF2DF8S] 
[XBMUXFF2DF16S] 
[XBMUXFF2DF4S] 
[XBMUXFF2DH16S] 
[XBMUXFF2DF8S] 
[XBMUXFF2DH2S] 
[XBMUXFF2DH3S] 
[XBMUXFFB2DH4S] 
[XBOR4DF4S] 
[XBOR4DF6S] 
[XBOR4DF12S] 
[XBOR4DF8S] 
[XBOR5DF6S] 
[XBOR5DF4S] 
[XBOR5DF8S] 
[XBOR5DF12S] 
[XBOR5DF16S] 
[XBOR5DF24S3 
[XBOR6DF16S] 
[XBOR6DF6S] 
[XBOR6DF8S] 
[XBOR6DF12S] 
[XBOR6DF24S] 
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[XBOR6DF4S] 

[XBOR7DF4S] 

[XBOR7DF32S] 

[XB0R7DF6S] 

[XBOR7DF8S] 

[XB0R7DF12S] 

[XBOR8DF24S] 

[XB0R8DF4S] 

[XBOR8DF6S] 

[XBOR9DF24S] 

[XBOR9DF6S] 

[XBOR9DF4S] 

[XBOR10DF6S] 

[XB0R11DF6S] 

[XBOR2DF4S] 

[XB0R2DF6S] 

[XBOR2DF2S] 

[XBORFFB3DF6S] 

[XB0RFFB3DF12S] 

[XBORFFB3DF3 2S] 

[XBORFF3DH6S] 

[XBORFF3DH2S] 

[XBORFF3DF6S] 

[XBORFF3DF16S] 

[XBORFF3DF24S] 

[XBORFF3DF8S] 

[XBORFF3DF12S] 

[XBORFF3DF4S] 

[XBORFF3DH8S] 

[XBORFF7DF4S] 

[XBORFF7DF16S] 

[XBORFF7DF2S] 

[XB0RFF4DH4SJ 

[XB0RFF4DH6S] 

[XBORFF4DF16S] 

[XBORFF4DH2S] 

[XBORFF4DH16S] 

[XB0RFF4DF24S] 

[XBORFF4DF3 2S] 

[XBORFF4DF6S] 

[XBORFF4DF8S] 

[XBORFF9DH4S] 

[XB0RFF1 7DH 6 S ] 

[XBORFF6DH6S] 

[XBORFF6DF6S] 

[XBORFF6DF4S] 

[XBORFF13DF24S] 

[XBORFF13DF32S] 

[XBORFF11DF24S] 

[XBORFF11DF32S] 

[XBORFF8DH2S] 

[XBORFF8DF24S] 

[XBORFF8DF3 2 S ] 

[XBMUXFF8DF4S] 

[XBMUXFF8DH2S] 

[XBXOR2DF4S] 

[XBMUXFF4DF4S] 

[XBMUXFF4DH2 S ] 

[XBMUXFF6DH24S] 

[XBMUXFF9DF6S] 

[XBMUXFF3DH24S] 

[XBBUFDF2S] 

[XBBUFDH2S] 

[SCSYNCHLL] 

[CGCLOCKBIAS] 

[HC] 

** Warning: No nets connected to component CGCLOCKBIAS. 
Translating. . . 
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[XBC01DF16S] 

[XBC01DF4S] 

[XBC01DF8S] 

[XBCM0S2ECLDF2S] 

t XBBUFD Fl 6 S ] 

[XBFFDH6S] 

[XBFFDF24S] 

[XBFFDF32S] 

[XBFFDH12S] 

[XBFFDH24S] 

[XBFFDH3S] 

[XBFFBDH12S] 

[XBFFDF6S] 

[XBFFDF12S] 

[XBFFBDF3 2S] 

[XBFFDF16S] 

[XBFFDH2S] 

[XBFFDF2S] 

[XBFFDF4S] 

[XBFFDF8S] 

[XBOR3DF6S] 

[XBOR3DF8S] 

[XBOR3DF12S] 

[XBOR3DF2S] 

[XBOR3DF4S] 

[XBOR14DF8S] 

[XBORFF5DF24S] 

[XBORFF5DH6S] 

[XBORFF5DH12S] 

[XBORFFB5DF32S] 

[XBORFF5DF4S] 

[XBORFF5DF12S] 

[XBORFF2DH8S] 

[XBORFF2DF2S] 

[XBORFF2DF24S] 

[XBORFF2DH6S] 

[XBORFF2DH16S] 

[XBORFF2DH24S] 

[XBORFF2DF12S] 

[XBORFFB2DF4S] 

[XBORFF2DF4S] 

[XBORFF2DF6S] 

[XBORFF2DF8S3 

[XBMUXFF2DF16S] 

[XBMUXFF2DF4S] 

[ XBMUXFF2 DH1 6 S ] 

[XBMUXFF2DF8S] 

[XBMUXFF2DH2S] 

[XBMUXFF2DH3S] 

[XBMUXFFB2DH4S] 

[XBOR4DF4S] 

[XBOR4DF6S] 

[XB0R4DF12S] 

[XBOR4DF8S] 

[XBOR5DF6S] 

[XB0R5DF4S] 

[XBOR5DF8S] 

[XBOR5DF12S] 

[XBOR5DF16S] 

[XBOR5DF24S] 

[XBOR6DF16S] 

[XBOR6DF6S] 

[XBOR6DF8S] 

[XBOR6DF12S] 

[XBOR6DF24S] 

[XBOR6DF4S] 

[XBOR7DF4S] 

[XBOR7DF32S] 


Exhibit C7 


Page 542 of 703 


[XBOR7DF6S] 

[XBOR7DF8S] 

[XBOR7DF12S] 

[XBOR8DF24S] 

[XBOR8DF4S] 

[XBOR8DF6S] 

[XBOR9DF2 4 S ] 

[XBOR9DF6S] 

[XBOR9DF4S] 

[XBOR10DF6S] 

[XB0R11DF6S] 

[XBOR2DF4S] 

[XBOR2DF6S] 

[XBOR2DF2S] 

[XBORFFB3DF6S] 

[XBORFFB3DF12S] 

[XBORFFB3DF32S] 

[XBORFF3DH6S] 

[XBORFF3DH2S] 

[XBORFF3DF6S] 

[XBORFF3DF16S] 

[XBORFF3DF24S] 

[XBORFF3DF8S] 

[XBORFF3DF12S] 

[XBORFF3DF4S] 

[XBORFF3DH8S] 

[XBORFF7DF4 S ] 

[XBORFF7DF16S] 

[XBORFF7DF2S] 

[XB0RFF4 DH4 S ] 

[XBORFF4DH6S] 

[XBORFF4DF16S] 

[XBORFF4DH2S] 

[XBORFF4DH16S] 

[XB0RFF4DF24S] 

[XBORFF4DF3 2 S ] 

[XBORFF4DF6S] 

[XBORFF4DF8S] 

[XBORFF 9DH4 S ] 

[XBORFF1 7DH6S ] 

[XBORFF6DH6S] 

[XBORFF6DF6S] 

[XBORFF6DF4S] 

[XBORFF1 3DF2 4 S ] 

[XBORFF1 3DF3 2 S ] 

[XBORFF1 1DF2 4 S ] 

[XBORFF11DF32SJ 

[XBORFF8DH2S] 

[XBORFF8DF2 4 S ] 

[XBORFF8DF32S] 

[XBMUXFF8DF4S] 

[XBMUXFF8DH2S] 

[XBXOR2DF4S] 

[XBMUXFF4DF4S] 

[XBMUXFF4DH2S] 

[XBMUXFF6DH24S] 

[XBMUXFF9DF6S] 

[XBMUXFF3DH24S] 

[XBBUFDF2S] 

[XBBUFDH2S] 

[SCSYWCHLL] 

[CGCLOCKBIAS] 

[HC] 

Netlist Info : 


Number of logic types : 130 
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Number of nets 
Number of components 
Number of component pins 
Number of pins/comp 
Number of nets/comp 


2306 

1091 

10914 

10 . 003666 

2 .113657 


Size estimation 


size | 


| # inst | size/inst | total 


| XBMUXPF2DF8S 

| 3 

1 1 

1 3 

| XBFFDH3S 

| 12 

1 1 

| 12 

| XBORFF2DF2S 

1 2 

| 1 

1 2 

j XBOR4DF6S 

| 30 

| 1 

| 30 

i XBFFDH24S 

1 1 

| 1 

| 1 

j XBORFF6DF4S 

| 1 

1 1 

1 1 

| XBOR6DF8S 

i 1 

1 1 

| 1 

| XBFFDF8S 

1 5 

1 1 

1 5 

| XBMUXFF2DF4S 

1 4 

| 1 

1 4 

| XBORFF2DH6S 

| 10 

| 1 

1 10 

| XBORFF5DF12S 

1 1 

1 1 

1 1 

| XBFFBDF32S 

1 4 

1 1 

1 4 

| XBORFF4DF3 2S 

1 2 

| 1 

1 2 

| XBOR6DF4S 

S 6 

1 1 

1 6 

| XB0RFF9DH4S 

1 1 

| 1 

1 1 

| XBORFF13DF32S 

1 3 

| 1 

1 3 

| XBORFFB3DF6S 

| i 

1 1 

| 1 

| XB0RFF2DH16S 

j 4 

1 1 

1 4 

| XBOR8DF6S 

1 2 

I 1 

1 2 

| XBFFBDH12S 

1 4 

1 1 

i 4 

j XBOR3DF12S 

1 1 

1 1 

1 1 

| XBORFF4DF24S 

1 1 

1 1 

1 1 

| XBMUXFF4DH2S 

1 i 

| 1 

1 1 

| XBORFF13DF24S 

1 1 

1 1 

| 1 

| XBFFDF16S 

| 12 

1 1 

| 12 

| XBOR5DF16S 

1 3 

1 1 

1 3 

| XBORFF6DH6S 

1 1 

i 1 

1 1 

| XBORFF5DH12S 

1 1 

| 1 

| 1 
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XBORFF8DF32S 

XBORFF4DH4S 

SCSYNCHLL 

XBMUXFF2DH16S 

XBORFF3DH8S 

XB0RFF4 DF 1 6 S 

XBOR3DF6S 

XBC01DF4S 

XBBUFDH2S 

XBORFF8DF24S 

XB0RFF5DF4S 

XBOR5DF8S 

XBOR7DF12S 

XBOR14DF8S 

XBMUXFF8DH2S 

XBFFDF32S 

XBOR3DF2S 

XBBUFDF16S 

XBORFFB5DF3 2 S 

XBMUXFF2DH3S 

XBOR5DF4S 

XBBUFDF2 S 

XBORFF4DF8S 

XBOR7DF6S 

XBFFDH12S 

XB0RFF3DF24S 

XBFFDF2S 

XBORFFB2DF4S 

XBORFF4DH2S 

XB0RFF5DH6S 

XBORFF4DF6S 

XBOR6DF24S 

XBOR9DF4S 

XBOR2DF6S 


1 [1 | 1 

2 | 1 | 2 
9 | 1 | 9 

6 | 1 j 6 

1 | 1 | 1 

2 | 1 | 2 

2 [ 1 | 2 

1 | 1 | 1 

3 | 1 | 3 

2 [1 j 2 

2 | 1 j 2 

4 | 1 | 4 
1 | 1 | 1 
4 | 1 | 4 

7 | 1 | 7 
7 | 1 j 7 

3 | 1 | 3 
3 | 1 | 3 

I | 1 | 1 
34 [ 1 | 34 

II | 1 | 11 
16 | 1 j 15 
7 | 1 | 7 
1 | 1 | 1 
1 | 1 | 1 

1 | 1 | 1 

2 | 1 | 2 
1 | 1 | 1 

7 | 1 | 7 
1 | 1 | 1 

8 | 1 | 8 
6 i 1 | 6 
1 | 1 j 1 
8 | 1 | 8 
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XBORFF2DH8S 

XBORFF3DF16S 

XB0R11DF6S 

XBC01DF16S 

XBOR4DF8S 

XBOR6DF12S 

XBFFDF6S 

XB0R2DF2S 

XBORFF3DF12S 

XBORFF8DH2S 

XB0R4DF4S 

XB0RFF1 1DF3 2 S 

XB CMOS 2 E CLDF 2 S 

XBORFF3DF8S 

XBOR6DF6S 

XBORFF7DF16S 

XB0RFF2DF24S 

XB0RFF2DH24S 

XBMUXFF2DH2S 

XBORFF11DF24S 

XBFFDF12S 

XBMUXFF4 DF4 S 

XBORFF4DH6S 

XBORFF3DH2S 

XBORFF3DF6S 

XBOR5DF24S 

XBOR8DF4S 

XBFFDH2S 

XBOR7DF32S 

XBFFDH6S 

XBORFF4DH16S 

XBMUXFFB2DH4S 

XBMUXFF3DH24S 

XBOR10DF6S 


1 | 1 | 1 

3 | 1 | 3 
1 | 1 | 1 
1 | 1 | 1 

4 | 1 | 4 

4 | 1 | 4 

1 | 1 j 1 

11 | 1 | 11 

2 | 1 | 2 
1 | 1 | 1 
48 | 1 | 48 

1 | 1 | 1 
20 | 1 | 20 

5 | 1 | 5 

3 | 1 | 3 

2 | 1 | 2 
1 | 1 | 1 
1 | 1 | 1 
312 | 1 j 312 

1 | 1 | 1 

6 | 1 | 6 

8 | 1 | 8 

9 | 1 | 9 

2 | 1 | 2 

2 | 1 | 2 
1 | 1 | 1 
1 j 1 | 1 

12 | 1 | 12 
1 | 1 | 1 
1 | 1 | 1 
1 | 1 j 1 
9 j 1 | 9 
32 i 1 | 32 

3 | 1 | 3 
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XBOR5DF12S 

XBORFF3DF4S 

XBOR3DF8S 

XBXOR2DF4S 

XBORFF2DF12S 

XBFFDF24S 

XBMUXFF8DF4S 

XBOR3DF4S 

XBORFF17DH6S 

XBOR9DF24S 

CGCLOCKBIAS 

XBORFFB3DF32S 

XBOR5DF6S 

XBORFF2DF8S 

XBOR7DF8S 

XBORFF7DF4S 

XBORFF3DH6S 

XBC01DF8S 

XB0RFF2DF6S 

XBOR7DF4S 

XBORFF7DF2S 

XBOR9DF6S 

XBMUXFF2DF16S 

XBORFF5DF24S 

XBORFF2DF4S 

XBOR4DF12S 

XBFFDF4 S 

XBOR6DF16S 

XBOR2DF4S 

XBORFFB3DF12S 

XBMUXFF9DF6S 

XBORFF6DF6S 

XBOR8DF24S 

XBMUXFF6DH24S 


2 | 1 | 2 

1 | 1 | 1 
4 | 1 | 4 
48 | 1 | 48 
11 j 1 | 11 

2 | 1 | 2 
8 | 1 | 8 
71 | 1 | 71 
1 | 1 | 1 
1 | 1 | 1 
1 | 1 | 1 
1 | 1 | 1 

1 | 1 | 1 

2 | 1 | 2 
1 | 1 | 1 
1 | 1 | 1 
1 | 1 | 1 
1 | 1 | 1 
1 | 1 | 1 
4 | 1 | 4 
8 | 1 | 8 
1 j 1 | 1 

1 | 1 | 1 

2 | 1 | 2 
29 | 1 } 29 
2 | 1 | 2 

2 (1 | 2 

3 | 1 | 3 
61 | 1 | 61 

2 | 1 | 2 

3 | 1 | 3 

8 | 1 | 8 
2 | 1 | 2 

9 | 1 | 9 
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+ 

I 

+ 


I TOTAL 


| 1091 j 1 


+ 

| 1091 


Warning : No "SL_SIZE" attributes found on the cells! 
Default size (1) was used for all cells. 

To change this default add an attribute "SL_SIZE" to the cells. 

slnet > 22:47:29 Terminating Normally on 94/10/24 

Elapsed CPU time 00:00:17 

Elapsed wall time 00:00:20 
End of Program 


Normal Termination . . . 

Mon Oct 24 22:47:29 PDT 1994 

**** pcomp hcl-passl 

Mon Oct 24 22:47:29 PDT 1994 

sed -e ' s!DESIGN_NAME! hcl-passl ! ' -e " s ! EDIF_FILE ! hcl-passl . sdl ! " \ 

-e • s!CHIPROOT!/n/auspex/sl0/chip/euterpe! • -e ' s ! TECH_G PLACE i hcl- 
passl . gplace .mobi2 34 ! ' \ 

-e ' s I TECH_REDIT! hcl-passl. red it .mobi234 ! « \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/hcl-passl . vrf 
rm -f gards/hcl-passl . dff 
{echo " cd "abspath Vgards ; \ 

HOME=/n/auspex/slO/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/ tools/ si/ license/license . dat 
DISPLAY-clio : 0 . 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke pcomp hcl-passl -listing hcl- 
passl .pcomp . lis" | /usr/local/bin/rexec cyclops sh && sleep 10 && \ 

HOME=/n/auspex/ si O/chip/euterpe/ tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/license/license . dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION-5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -ds gards/hcl-passl ) | | (mv gards/hcl- 
passl .pcomp. lis gards/hcl-passl. pcomp. lis. ERROR; false) 

Requires a minimum license of gardsfel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS PCOMP 7.121 -- Physical Compiler 

Copyright (c) 1994 SILVAR-LISCO . All rights reserved. 
Design: hcl-passl Started at: 94/10/24 22:47:33 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: HC 
Processing Expansion level: SLNET 

. . . Start of netlist processing. 

. . . Circuit name : HC 

. , . Processing CDL. 

... CHIPNAME : SOFA; 


. . . Processing header of user PDL . 

. . . PHYSICALLIB : PBUILD ; 

. . . Processing header of system PDL. 

. . . PHYSICALLIB : PBUILD ; 

... Processing rest of user PDL. 

... Processing rest of system PDL. 

. . . Processing TDL. 
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... TECHNOLOGYLIB : SOFA; 

. . . Computed Grid_Size = 1000 

. . . Final Processing. 

. . . Successful physical compilation (with warnings) . 
>>> Loading logical netlist. 

. . . Successful completion. GARDS design file created. 

Terminated at : 94/10/24 22:47:46 

Elapsed CPU time : 0 Hrs 0 Mins 8 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 13 Sees 

Mon Oct 24 22:47:56 PDT 1994 

HOME=/n/auspex/sl0/chip/euterpe/ tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/license/ license .dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif gards/hcl-passl .pirn -xrf gards/hcl-passl .xrf 
-dff gards/hcl-passl . dff -noHole \ 

-obstructionPdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa .pdl 

\ 

-obstructionCdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa . cdl 

\ 

-libraryPdl gards/hcl-passlmacros . pdl -eel -tech mobi -sdl \ 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Preparing input files... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. pdl . . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Reading gards/hcl-passl .dff . .. 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Fetching bounding box from 
/n/auspex/ slO/chip/euterpe/gards/ sofa/ sofa . cdl . . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Checking 
/n/auspex/slO/chip/euterpe/gards/ sofa/ sofa. cdl for fixed obstructions... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Checking 
/n/auspex/slO/chip/euterpe/gards/sofa/sofa. cdl for Eel obstructions... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Processing the gards/hcl-passl .pirn 
file. . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex : 58 rows (58 non-empty) 
...spanning 28 columns (28 maximum cells/row) 

...for a total of 1087 cells were written to "gards/hcl-passl .pim.pif . 0 1 . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (3190, 479) to (3632, 
659) [221 by 60 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex; 93 94 ECL atoms placed in 13260 [-1660 
obstructions] atom area [80.98% dense] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: WARNING: Potential errors, check log 
file "gards/hcl-passl .pirn .warn' 

#pim2pif . ex Version 0.2.27 Sat Oct 15 16:22:33 PDT 1994 

HOME=/n/auspex/sl0/chip/euterpe/ tools 
LM_LICENSE_FlLE=/n/ auspex/slO/chip/euterpe/tools/sl/ license/ license .dat 
DISPLAY-clio : 0 . 0 SL_TOTAL_DURATION*=500 CHIPROOT=/n/auspex/ slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack gards/hcl-passl .pirn .pif -obstructionPdl 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa .pdl \ 

-obstructionCdl 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa . cdl \ 

-libraryPdl gards/hcl-passlmacros .pdl -eel -tech mobi \ 
-trueSqueeze 40 -distance 6 -packBothEdges 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Preparing input files... 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Fetching bounding box from 
/n/auspex/ slO/chip/euterpe/gards/sof a/sofa . cdl . . . 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl . . . 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Reading 
/n/auspex/ si 0/chip/euterpe/gards/sof a/sof a. pdl . . . 

/n/auspex/ slO/chip/euterpe/tools/bin/pif pack: Packing right edge... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: Final width 200 ECL atoms, squeezed 
out 21 ECL atoms 

. . .which may include up to 28 ECL atoms of obstructions 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 58 rows (58 non-empty) 
...spanning 27 columns (27 maximum cells/row) 

...for a total of 1087 cells were written to "gards/hcl-passl .pim.pif .packed' . 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (3190, 479) to (3590, 
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659) [200 by 60 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 9394 ECL atoms placed in 12000 [-1618 

obstructions] atom area [90.48% dense] 

#pim2pif.ex Version 0.2.27 Sat Oct 15 16:22:33 PDT 1994 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Packing left edge... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: Final width 200 ECL atoms, squeezed 
out 0 ECL atoms 

. . .which may include up to 22 ECL atoms of obstructions 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 58 rows (58 non-empty) 
...spanning 26 columns (27 maximum cells/row) 

...for a total of 1087 cells were written to "gards/hcl-passl .pirn. pif .packed' . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (3190, 479) to (3590, 
659) [200 by 60 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 9394 ECL atoms placed in 12000 [-1618 
obstructions] atom area [90.48% dense] 

#pim2pif.ex Version 0.2.27 Sat Oct 15 16:22:33 PDT 1994 

HOME=/n/auspex/sl0/chip/euterpe/ tools 
LM__LICENSE_FILE= /n/auspex/ slO/chip/euterpe/tools/sl/license/license . dat 
DISPLAY=clio: 0 .0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/pif 2pim 

gards/hcl-passl .pirn. pif .packed -xrf gards/hcl-passl .xrf -dff gards/hcl-passl . df f \ 
-obstructionPdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa. pdl 

\ 

-obstructionCdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa . cdl 

\ 

-libraryPdl gards/hcl-passlmacros .pdl -eel -tech mobi -sdl \ 
-collapseRows -noSpacers -noAlign -noOffset 

/n/auspex/slO/chip/euterpe/tools/bin/pif 2pim: Preparing input files... 

/n/auspex/slO/chip/euterpe/tools/bin/pif 2pim: Reading gards/hcl-passl . dff . . . 

/n/auspex/ slO/chip/euterpe/tools/bin/pif 2pim : Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. pdl . . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pif2pim: Fetching bounding box from 
/n/auspex/slO/chip/euterpe/gards/sofa/sofa.cdl . . . 

/n/auspex/ s 10/ chip/ euterpe/ tools /bin/pif 2pim: Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl . . . 

//n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 178 rows 28 columns written to 
"gards/hcl-passl . pirn . pif .packed . pim ' 

#pim2pif.ex Version 0.2.27 Sat Oct 15 16:22:33 PDT 1994 

mv gards/hcl-passl .pirn. pif .packed gards/hcl-passl . pif 

**** GPLACE he 1 -pas sl 

Mon Oct 24 22:48:38 PDT 1994 

sed -e 's!DESIGN_NAME!hcl-passl ! 1 -e "s ! EDIF_FILE i hcl-passl . sdl ! 11 \ 

-e ' sICHlPROOT! /n/auspex/ sl 0 /chip/eut erpe! » -e ■ s ! TECH_GPLACE ! hcl- 
passl , gplace . mobi234 ! 1 \ 

-e ' s !TECH_REDIT! hcl-passl . redit .mobi234 ! T \ 

< /n/auspex/ slO/chip/euterpe/proteus /mi sc/gards . vrf > gards/hcl-passl , vrf 
rm -f gards/hcl-passl .gplace .nic 

cd gards; if HOME=/n/auspex/sl0/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl /license/license. dat 
DISPLAY=clio: 0 . 0 SL TOTAL DURATION=500 CHIPROOT=/n/auspex/sl0 /chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -p -s hcl-passl; then \ 

/usr/5bin/echo 'deletegroup use; ok 1 > hcl-passl . gplace . nic ; fi 

/usr/5bin/echo 1 readpif hcl-passl .pif ; ok 1 >> 
gards/hcl-passl . gplace . nic 

/usr/5bin/echo 'makeauto use; ok' >> 
gards/hcl-passl . gplace . nic 

/usr/5bin/echo 1 iparam sweeps 0;' >> 
gards/hcl-passl . gplace . nic 

/usr/5bin/echo 'iparam algorithm hper_net length; 1 >> 
gards/hcl-passl .gplace . nic 

/usr/5bin/echo 'improve use; ok 1 >> 
gards/hcl-passl .gplace . nic 

/usr/5bin/echo 'writenof hcl-passl . nof ; use; ok' >> 
gards/hcl-passl .gplace . nic 

/usr/5bin/echo ' exitsave\nexitnosave ' >> 
gards/hcl-passl .gplace . nic 

(echo "cd "abspath" /gards ; \ 

HOME=/n/auspex/sl0/chip/ euterpe/tools 


Exhibit C7 


Page 550 of 703 


LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe /tools /si /license/license . dat 
DISPLAY=clio:0. 0 SL_TOTAL_DURATTON=50 0 CHIPROOT=/n/auspex/slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke gplace hcl-passl -listing hcl- 
passl . gplace . lis -cmdin hcl-passl . gplace . nic -colorin 
hcl-passl . gplace .mobi234 -inbat 1" | \ 

/usr/local/bin/rexec Cyclops sh && HOME=/n/auspex/slO/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/license/ license . dat 
DISPLAY=clio : 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -sp gards/hcl-passl) | | (mv gards/hcl- 
passl.nof gards/hcl-passl . nof . ERROR; rm -f hcl-passl . nof ; false) 


Requires a minimum license of xgplacel_3 or gardsl 3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 

Xlib: connection to "clio:0.0" refused by server 
Xlib: Client is not authorized to connect to Server 
Test: Error in opening display = clio:0.0 
GARDS GPLACE 7.12 6 General Placer 

Copyright (c) 1994 SILVAR-LISCO . All rights reserved. 
Design: hcl-passl Started at: 94/10/24 22:48:42 


GPLACE Version 7.1.26 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components. . . 

Loading nets . . . 

Loading logical types. . . 

Processing physical types... 

Loading cell_types. . . 

Creating net-comp xref table. . . 

gmake[2]: *** [gards/hcl-passl . nof ] Error 1 

gmake [2] : Leaving directory 
" /N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc 1 

gmake [1] : *** [hcl-base . short . nets] Error 1 

gmake [1] : Leaving directory 
-/N/auspex/root/slO/chip/euterpe/verilog/bsrc/hc 1 

gmake: *** [hclgards] Error 1 

gmake: "gards/hcl . obs ' is up to date. 

[finished at Mon Oct 24 22:52:26 PDT 1994 -- exit status 0] 
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Subject: 


Sent: 

To: 

Cc: 


From: 


John Campbell [solo@echidna] 
Tuesday, October 25, 1994 10:06 AM 
'Tim B. Robinson' 

'geert@ambiorix'; 'bpw@ambiorix'; , solo@ambiorix*; 'stick@ambiorix' 
Re: Planning, schedule , etc ... 


as Tim B. Robinson was saying 


. .Geert Rosseel wrote (on Sat Oct 15) : 

2. A stronger TTL DRAM I/O driver / Mnemo has to drive a 
lot more memory than Euterpe . 

3 . A PCI bus driver . . . Alan has a description of the specs 
of that driver . . . 

. .1 think we need to sit down and thrash out how we are going to handle . ,5V again. There 
is no point making a mongo ttl driver for the DRAMs . .if we have to buffer it outside 
anyway to handle the 5V. 


I agree with tim. I think that the way we could handle this is to use a buffer at the 
dram bus and the pci bus. this could be a 3v in 5v out circuit available from Idt etc. 
opposite translation on the way back. this may be perfectly adequate for what we are 
trying to do. 


. Tim 


regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: 


tbr 


To: 


Sent: 


Subject: 


Tuesday, October 25, 1994 11:02 AM 
'woody' 

forwarded message from Abbott/Furman 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil t nil t nil nil] 

["11356" "Thu" "25" "August" "1994" "00:26:53" "GMT" "Abbott/Furman" "Abbott/Furman" 
"<1994Aug25.002653.18346@microunity.com>" "213" "" " A From:" nil nil "8" nil nil (number " " mark " R 
Abbott/Furman Aug 25 213/1 1356 WW) nil] 

nil) 

Return-Path: <sysadm@gaea> 

Received: by gaea.microunity.com (4.1 /muse 1.3) 

id AA 18387; Wed, 24 Aug 94 17:27:06 PDT 
Received: from GATEWAY by microunity with netnews 

for euterpe@gaea (euterpe@gaea) 
Message-Id: <1 994 Aug25. 002653. 1 8346@microunity.com> 
Organization: MicroUnity Systems Engineering, Inc. 
From: Abbott/Furman 
Sender: sysadm@gaea 
To: euterpe@gaea 

Date: Thu, 25 Aug 1994 00:26:53 GMT 

This note is to report on the current, and still problematic, status 
of event handling in the Terpsichore architecture. 

We have dual objectives in this area: to minimize worst-case interrupt 
latency for all threads (since it contributes directly to the "bottom 
line" in real-time deadline budgets), and to eliminate if possible 
inter-thread interactions as contributors to interrupt latency (since 
they tend to increase worst-case latency). A major motivation for 
eliminating the r-thread from Euterpe was to avoid inter-thread 
interaction due to having all interrupts serialized by a single 
(r-)thread. Recently, we have discovered that the interrupt-based 
design still suffers to some degree from this effect. Specifically, 
reception of Calliope interrupts that are targeted at one thread may 
inadvertantly be delayed by the actions of another thread that is 
handling a different interrupt. 

Presumably, a traditional dedicated-wire approach to signalling 
interrupts in the Terpsichore system architecture was avoided because 
this approach does not scale well in a multiprocessor environment. 
However, even in a single-processor, single-I/O-chip environment, the 
event register model has proven to be a thorny problem. It seems 
worth reviewing the history of our design efforts: 

As Calliope is a slave Hermes device, it cannot autonomously generate 
the Hermes transactions that would set interrupt bits in the Euterpe 
event register. Instead, Euterpe is responsible for issuing 
non-blocking reads to the Calliope event register address. The 
response packet from Calliope, which contains the contents of the 
Calliope event register, is deferred until any Calliope event bit is 
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set; the results are then or'ed into Euterpe's event register. 

The current design makes software running on Euterpe responsible for 
ensuring that a non-blocking load to Calliope is always kept 
outstanding. When Terp had only the single r-thread to respond to 
interrupts, this solution seemed tenable: The first action of this 
software, when it detected a Calliope event, was to re-issue the 
non-blocking load by *writing* to Euterpe's event daemon address 
register location. Next, the software would begin executing the code 
necessary to handle the event. If a second Calliope event was 
signalled now, there was no mechanism, short of polling the event 
register, by which the corresponding daemon event store would be 
performed until the event handler finished. Therefore, any Calliope 
events that occurred * after* that second event would not be visible to 
Euterpe until the first event handler completed. This did not seem to 
be problematic because Euterpe was busy servicing the first event and 
did not have the cycles available to handle the later ones anyway. 
(This ignores the possibility of having high-priority events that 
preempt low-priority ones.) 

Several problems arose in the changeover to the interrupt-based 

Euterpe. The first problem arose because of a "feature" of the Hermes 

protocol: Multiple outstanding Hermes accesses to the same address are 

not permitted. (This is to allow for the possibility of error 

recovery in the face of reordered transactions when interfacing to, 

say, a Mnemosyne chip.) The Hermes Channel controller (HC) on Euterpe 

enforces this rule by comparing the addresses of each new access to 

all of the outstanding ones. If HC sees a match (actually a match in 

the lower six bits), it will not issue *any* transactions to the 

channel until the blocking transaction completed. Unfortunately, if 

the transaction that is stalling HC is a non-blocking load, Calliope 

will not send back a response until an event bit is raised in the 

Calliope event register - a potentially distant occurrence. 

Meanwhile, the Hermes channel would back up into the non-blocking load 

buffer and eventually one or more threads in Euterpe would seize up 

until Calliope finally generated an event. 

In the interrupt-based Euterpe there is not one thread, but five, each 
fielding different Calliope events. However, no one was able to 
devise a software protocol that would ensure that at most one 
non-blocking read of the Calliope's event register was ever 
outstanding, short of serializing all the daemon event stores through 
a single hardware thread. This last possibility was unacceptable 
because it was exactly the sort of situation we were trying to avoid 
when we abandoned the r-thread. 

Even if the unique address aspect of the Hermes protocol were dropped, 
the current implementation of Calliope does not keep track of multiple 
outstanding non-blocking loads of its event register. In effect, 
Calliope would simply discard the oldest read transactions aimed at 
its event register when new ones arrived. On Euterpe, the Hermes 
transaction IDs associated with these discarded accesses would become 
forever unusable, until none remained for use by new transactions and 
the Hermes channel would effectively be disabled. 

The compromise adopted was to make HC recognize the special accesses 
that took place through the daemon event register, and to discard them 
if another one was already in progress. Now the onus was still upon 
the software to perform the non-blocking access, but no harm would 
come from doing this more than once. 
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"If the hardware is tracking these special non-blocking accesses 
already", someone asked, "then why can't *hardware* re-issue the load 
transaction to Calliope on its own ?", The problem is that event bits 
in Calliope remain set until the software handler in Euterpe clears 
them. Therefore, any non-blocking accesses made to Calliope while an 
event bit is set will immediately be answered. Until the Euterpe 
handler clears the relevant event bit on Calliope, the two chips will 
exchange a continuous volley of packets, robbing the channel of usable 
bandwidth. Tbr estimated that, with current Calliope latencies, about 
1/6 of the channel's throughput would be consumed. Presumably, as we 
improve Calliope's latency and/or add more Calliope modules to the 
same channel, this problem would grow worse; it also adds a minor 
source of unpredictability to Hermes response time for all threads. 

Nonetheless, it was thought that the latest proposal was a workable 
solution to the problem. Recently we have realized that the 
supposedly independent interrupt processing by different threads has 
not been entirely decoupled. Consider thread "A", which handles two 
different event types, "Al " and "A2". These two events could both be 
Calliope events or possibly "Al" could be a "soft" event, generated by 
another thread, for example, to trigger a change in scheduling. 
Another thread, "B", handles Calliope event type "Bl". All these 
event handlers are so-called "fast" event handlers, meaning that they 
are directly executed in interrupt mode. The simplified dispatch and 
context-saving mechanisms used for fast threads are intended to be 
especially efficient and are used only for the highest-rate event 
handlers on each thread, in keeping with a rate-monotonic scheduling 
discipline. 

The following example shows how the service of Bl can be delayed by 
the thread servicing Al : 


Calliope Euterpe 
Event Reg Event Reg 


Thread "A" 


Time 


Thread "B" 


Al 



Al 

Al 

Enter interrupt mode 

Al 

Al 

Reset event regs 



Daemon event store 

A 

A2 


1 

Service Al 

A2 

A2 

1 

A2+B1 

A2 

V 

A2+B1 

A2 


A2+B1 

A2 

Read event register 

A2+B1 

A2 

Reset event regs 

Bl 


Daemon event store 

Bl 

Bl 

Interrupt mode 

Bl 

Bl 

A Reset event regs 



| Daemon event store 



1 

Service A2 Service B 1 

Bl 


1 

Bl 

Bl 

1 MISSED DEADLINE 
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The problem is that once a thread is servicing an interrupt in 
interrupt mode, it won't notice further interrupts. One way to solve 
this is to execute the event service code in normal (non-interrupt) 
mode. This approach will reduce the magnitude of the problem, but it 
still won't eliminate it; almost every cycle spent in interrupt mode, 
while oblivious to further interrupts, must still be considered as a 
potential cycle of latency added to interrupts destined for other 
threads. 

Also, servicing events in normal mode has significant overhead, which 
makes it less desirable for high-rate events. A "generic" event 
handler that runs in interrupt-mode would save some registers and then 
vector to a "specific" handler code by use of the BBACK instruction, 
which would execute in normal mode. But how does the specific handler 
code resume execution of the code that was preempted when the generic 
handler was first started ? There does not seem to be any way of 
restoring all 64 registers and the PC except from interrupt mode. The 
specific handler code must itself generate a fake or "soft" event when 
it completes execution in order to trigger the resumption of the 
preempted code. This is not merely ugly - it represents further 
erosion of Euterpe's ability to meet deadlines: 


Calliope Euterpe 

Event Reg Event Reg Thread "A" 


Al 

Al Al Enter interrupt mode 

Al Al Reset event regs 

Daemon event store 
Save PC, Rl of preempted thread 
BBACK to service A 1 
Re-enter normal mode 


I 

Service Al 

! 

Time | 
v 

Generate a soft event 
Enter interrupt mode 
Setup post-event PC, Rl 
BBACK to resume preempted thread 


Is there some software mechanism that we can concoct to make the 
current interrupt mechanism work better? If not, what hardware 
changes are necessary? Can we avoid changes to Calliope? Finally, we 
can also ask about the long-term viability of this scheme. After all, 
how can an interrupt-de livery scheme be "scalable" when it does not 
work well with only one processor and one I/O controller? 
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End of forwarded message 
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From: B. P. Wong [bpw@frodo] 

Sent: Tuesday, October 25, 1994 11:08 AM 

To: 'tbr@aphrodite'; 'solo@echidna' 

Cc: 'geert@ambiorix'; 'bpw@ambiorix'; , solo@ambiorix'; 'stick@ambiorix' 

Subject: Re: Planning, schedule , etc ... 


> as Tim B. Robinson was saying 


Geert Rosseel wrote (on Sat Oct 15) : 

2 . A stronger TTL DRAM I/O driver / Mnemo has to drive a 
lot more memory than Euterpe . 

3 . A PCI bus driver . . . Alan has a description of the specs 
of that driver . . . 

. .1 think we need to sit down and thrash out how we are going to 
handle . . 5V again. There is no point making a mongo ttl driver for 
the DRAMs . .if we have to buffer it outside anyway to handle the 5V. 

. .Tim 


> I agree with tim. I think that the way we could handle this is to use 

> a buffer at the dram bus and the pci bus. this could be a 3v in 5v 

> out circuit available from Idt etc. opposite translation on the way 

> back. this may be perfectly adequate for what we are trying to do. 
> 

> regards, EMail solo@microunity.com 

> solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 

This option will cut down our risk very significantly. At this point in time I do not 
believe we have a solution to the 5V driver design, if the NM0S drains cannot be exposed 
to 5V. This option will also eliminate the di/dt noise. 

IDT is not the only vendor for such an interface part. There are quite a few vendors 
including the good old timers viz. motorola, TI, National and some newer vendors like QSI 
and Cypress (interface logic division that used to be Performance semiconductor) . 


bpw 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Tuesday, October 25, 1994 11:41 AM 
To: 'Bill ZuravlefT 

Cc: 'Brian Smith'; 'Richard Dickson'; 'Derek Iverson'; 'Jeff Marr'; 'Mark Semmelmeyer'; 'Tim B. 
Robinson'; 'Jay Tomlinson' 

Subject: Hexlet stores to periphery 


Bill Zuravleff wrote (on Mon Oct 24): 
Brian and Lisa Please read.'! 
Vail, 

I've checked in and released a change to NB to make 

hexlet stores work, that is hexlet stores to the "periphery" - 

DR, HC, Slow Peripherals (if you thought they worked before, 

holler). The problem was I and NB was interpreting MCstrDatS10S13 

for a hexlet store to be low octlet first, whereas it's 

high octlet first. Octlet stores were working because the data 

was being repeated on S10,l 1 and S12,13. 

This order on MCstrDat is somewhat unfortunate because, 

1 ) for hexlet store, NB continues to issue low octlet packet of hexlet first, 
and low 32 bits of octlet first within a packet. 

2) *if* a NB bypass is contemplated or desired, we'll have to change something 
other than NB to get minimum latency 

but, hey I can live with it. 

Brian: Note well, you'll have to change your Store Hexlet routine 
to put hight octlet first on din bus, after you've updated to 
latest NB. 

Lisar: can you please add a sl28*b*i instruction, then 1128bi to 
dram_store_unique, or an appropriate test. 

Yep, that is in the test we just hadn't got there. I picked up the 
change to nb along with BOM 157 and dram_store_unique ran ok. 

Thanks, 
billz 


Design Name: d_euterpe_wrap 
Run Date: 251094 
Run ID: 19933 


Using BOM: 

Version BOM,v 157.nb 157.0 + nb fix 1994/10/24 12:49:58 LT woody 


Warning: Local BOM is out of date: 
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File: BOM Status: Needs Merge 

Version: 157.0 Mon Oct 24 18:45:21 1994 

RCS Version: 157.1 /u/chip/chip-archive/euterpe/verilog/bsrc/BOM,v 
Sticky Tag: (none) 
Sticky Date: (none) 
Sticky Options: (none) 


Simulator: d_euterpe_wrap.mif.mm was built on Mon Oct 24 23:29:38 1994 

Run started on host: nosferatu at: Tue Oct 25 02:27:36 PDT 1994 

dram_0 Ran ok 
dramloadO Ran ok 
dramprint_l Ran ok 
dram_store_unique_0 Ran ok 
exrescruel_0 Ran ok 
sysprotol_l Failed 
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From: Buffalo Chip [chip@rhea] 

Sent: Tuesday, October 25, 1994 1:30 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 60.0 initiated by woody completed @ Tue Oct 25 
11:28:56 PDT 1994 with exit status 0.. chip 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Tuesday, October 25, 1994 2:03 PM 
To: 'tbr@nosferatu' 
Subject: forwarded message from Jeff Marr 

Start of forwarded message 


Still worried about this. 


Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["768" "Tue" "25" "October" "1994" "1 1:55:40" "-0700" "JeffMarr" "jeffrn@kephalos " nil "25" "idiot is me - 
exmaskeasy" " A From:" nil nil "10"]) 
Return-Path: <jeffm@kephalos> 

Received: from nosferatu.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA2I780; Tue, 25 Oct 94 1 1:55:42 PDT 
Received: from kephalos.microunity.com by nosferatu.microunity.com (8.6.4/muse-sw.2) 

id LAA1 1 120; Tue, 25 Oct 1994 1 1:55:41 -0700 
Received: from localhost by kephalos.microunity.com (8.6.4/muse-sw.2) 

id LA A 1 1708; Tue, 25 Oct 1994 1 1:55:40 -0700 
Message-Id: <199410251855.LAA1 1708@kephalos.microunity.com> 
In-Reply-To: <1 994 10251 84 l.LAA10967@nosferatu.microunity.com> 
References: < 1994 1025 1840. LA A 11 682@kephalos.microunity.com> 

<1 994 1 025 1 84 1 .LAA 1 0967@nosferatu.microunity.com> 
From: jeffm@kephalos (JeffMarr) 
To: lisar@nosferatu (Lisa Robinson) 
Subject: idiot is me - exmaskeasy 
Date: Tue, 25 Oct 1994 1 1:55:40 -0700 

Lisa Robinson writes: 

> 

> JeffMarr wrote (on Tue Oct 25): 
> 

> Well, I just got bit by the "I always use base registers properly" come-uppance. 

> 

> Ack. I will fix. 

> 

> jefftn 

> 

> How about the other exmask tests? 

> 

> Lisa R. 

I have asked Lisa Repka to put the change back into terp, so we can screen all 
of our tests. We should be able to do that this afternoon. Lisa had taken it out 
because the compiler, it turns out, causes exception 9's all over the place. 
She is going to have to do some work to the compiler. 

This puts all compiled code temporarily at risk - a possible workaround is to turn 
all optimization off. This experiment can be done this afternoon, when we get 
a new terp. 

Are there any tests that need screened this morning? 
jeffm 
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- End of forwarded message - 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, October 25, 1994 2:45 PM 
'software-checkins-dist' 
gnu-tools/sim/terp run.c memory. c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/ sim/terp 

Modified Files: 

run.c memory. c 
Log Message: 

Allow exception 9 (base address (== ra) != computed address) to be turned on/off from the 
command line. Default is on if RE ALLY_AC CURATE_S IMULAT I ON (i.e. on suns), and off 
otherwise . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, October 25, 1994 8:36 PM 
'software-checkins-dist' 
gnu-tools/sim/terp group.c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 

group . c 
Log Message : 

grotll28, gshrl28, grotrl28 and gushrl28, with a shift count of 64, need to be careful not 
to clobber the src too soon. 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Lisa Robinson [lisar@nosferatu] 
Tuesday, October 25, 1994 10:32 PM 
, tom@nosferatu'; Vant@nosferatu' 

'hopper@nosferatu'; 'vo@nosferatu'; 'tbr@nosferatu'; 'geert@nosferatu' 
emerge 


Well I finally got back to trying to build an edif2 from the spivs and spite seemed to do 
the "right" thing but emerge memory faulted. 

See /n/nosferatu/s2/euterpe/verilog/lvs/makerrs 


Reading edif library enetlib 

Merging libraries with input edif 
/bin/sh: 11629 Memory fault 
gmake: *** [euterpe . edif 2] Error 13 9 


Lisa R. 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Tuesday, October 25, 1994 10:45 PM 

To: 'pandora@aphrodite' 

Cc: 'paulb@aphrodite' 

Subject: Belated meeting notes 


Some notes from a meeting last week. 

Gmo has found that the vendor of choice for PCI SCSI controllers is Bus Logic. This is 
based on discussions on the net and from notes inthe Linux distribution which say it 1 s the 
only one to consider. 

There is no corresponding clear choice for RGB and Ethernet. 
No serial interfaces have come to light so far. 

Action: gmo to work with wkm to get more data and technical manuals 
on a selection of boards. 


gmo reported it will cost $4 OK to upgrade our OSF license to V 1.2.2 (A further 
redistribution fee of $35K would have to be payed before we can ship products using it.) 
After a brief discussion it was agreed OSF is still the correct choice. 


Mouss noted that Tony Stelliga may have contacts with PCI experience. 
Action: tbr to ask tony for contacts. 


Vandyke has already ordered a second Pentium nachine for PCI driver development. 
The speclnt 92 benchmarks have compiled OK with the latest compiler. 

Spec8 9 will be compiled soon. The IEEE fp emulation package is being dusted off to allow 
the specFP set to be run. 


Next meeting Friday 3pm 
Tim 
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From: 
Sent: 
To: 

Subject: 


Lisa Robinson [lisar@nosferatu] 
Wednesday, October 26, 1994 2:10 AM 
'pandora@nosferatu' 
Building the Pandora Schedule 


In order to put together a comprehensive Pandora schedule I would like to call a series of 
focussed meetings to identify all of the tasks to be accomplished, their dependancies and 
estimated durations given current resources. 

This will be followed by an integration of these tasks lists into an overall Pandora 
schedule. 

The following will be discussed in separate meetings: 

1. Mnemosyne design and verification through to tested 
packaged parts . 

2. System level architecture through board level design. 

3. System software development, System hardware verification, 
System software verification. 

4. System mechanical and electrical design. 

5. System bringup - here we may need to start by reviewing the 
current hestia bringup schedule. 

6 . Foundry Euterpe . 

The initial meetings will be held over the next week in the engineering conference room: 

1. Thursday - 1.3 0 - 3.00pm 

2. Monday - 10.30 - 12,00pm 

3. Monday - 1.3 0 - 3.00pm 

4. Thursday - 11.00 - 12.3 0pm 

5 . Thurday - 1.30 - 3.0 0pm 

6. TBD 

Let me know if you have a problem with the time. 


Lisa R. 
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From: vant [vanthof@hestia] 

Sent: Wednesday, October 26, 1994 8:1 1 AM 

To: Tim B. Robinson' 

Cc: 'Dave Van't Hof ; 'Mark Hofmann' 

Subject: Re: calliopel Ivs finally finished 

Tim B. Robinson writes: 

> 

>Great news, but did we never get any insight into what "slow mode" is? 
>What else do you feel has to happen before we can trust 1SS for the 
>final run? 

> 

>Tim 

> 

There is some work to the Ivs flow to fix the substrate connections, then 
some amount of time must be spent in studying the hierarchy of our chips 
to figure out the right combination of 'explode' and 'flatten' lists for 
ISS. I'm hoping to start this sometime soon on euterpe. 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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From; vant [vanthof@hestia] 

Sent: Wednesday, October 26, 1 994 8:23 AM 

To: 'Lisa Robinson' 

Cc: 'tom@nosferatu'; Vant@nosferatu'; , hopper@nosferatu'; 'vo@nosferatu'; 'tbr@nosferatu'; 

'geert@nosferatu' 
Subject: Re: emerge 


Lisa Robinson writes : 

>Well I finally got back to trying to build an edif2 from the spivs and 
> spite seemed to do the "right" thing but emerge memory faulted. 

>See /n/nosf eratu/s2/euterpe/verilog/lvs/makerrs 


> Reading edif library enetlib 
> 

> Merging libraries with input edif 
>/bin/sh: 1162 9 Memory fault 

>gmake; *** [euterpe . edif 2] Error 13 9 


>Lisa R. 


There is one error associated with the emerge run, the library 'enetlib' 
is 

missing. However, that should not cause memory faults. I believe there were changes made 
to spite to handle 'globals'? emerge/topt have a limited and most likely different 
approach in handling globals. What syntax is spite generating in the edif netlist as I'm 
pretty sure emerge/topt don't handle it. 

Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! (tm) All kids love Log I #incluce 
<std_disclaim. h> 
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From: Derek Werson [doi@demeter] 

Sent: Wednesday, October 26, 1994 10:27 AM 

To: 'ericm@demeter' 

Cc: Tom Laidig'; Tim B. Robinson' 

Subject: Re: source repository 

I have included in this message the crib sheet I put together 
to give an overview of CVS, BOMs, and a few other issues and 
a copy of the README file that can be checked out from local/src. 
I would also recommend looking at the CVS man page. It should 
be considered a 'man book' instead of a man page but it does 
have lots of good information. Also, there are man pages available 
for all the BOM related tools (as well. as a -h command line option 
that gives a slightly shorter version). 

I would also be more than happy to give a little 'tutorial' on 
CVS and BOM related issues 

Derek 


Here is the crib sheet I put together 


Common CVS Commands and their Usage 


cvs checkout Check out sources from the repository into 
cvs co the local work area. The co' and 'checkout' 

commands are synonymous. 

cvs add Tells CVS that you plan on adding a file or 

directory to the repository. 
If you are adding a file a commit is also 
required. 

cvs remove Tells CVS that you plan on removing a file. 

(A removed file is actually put into an 'Attic' 
A commit is required to complete the operation. 

cvs commit Make any change to a file permanent. CVS 

cvs ci will verify that you changes are derived 

from a current source before updating the 

repository. The 'ci' and 'commit' 

commands are synonymous. 

cvs update Update any local out-of-date sources from 

that found in the repository. 

cvs status Give me information about the file (both locally 

and in the repository) 

cvs log Print out any log messages supplied with 

previous commits (or checkins). 

cvs diff Show me differences between any two versions 

of a file. 


Exhibit C7 


Page 571 of 703 


Bill Of Materials - BOM 


BOM files provide us with a mechanism to identify specific files and 
subdirectories for later retrieval. 


Example BOM file: 

# Created by mkbom 

# $Id: BOM,v 3.5 1994/01/18 13:57:07 LTtbr Exp $ 


File 

1.1 

.checkoutrc 

File 

1.16 

Makefile 


File 

1.34 

Makefile.defs 

File 

1.44 

Makefile.rules 

Dir 

2.0 

BOM 

clockbias 

Dir 

5.0 

BOM 

compass 

Dir 

2.0 

BOM 

custom 

Dir 

2.0 

BOM 

dcell 

Dir 

2.0 

BOM 

doc 

Dir 

2.0 

BOM 

exlax 

Dir 

2.0 

BOM 

gards 

Dir 

2.0 

BOM 

gardswarts 

Dir 

3.0 

BOM 

ged 

Dir 

2.0 

BOM 

iss 

Dir 

6.0 

BOM 

leafgen 

Dir 

3.0 

BOM 

misc 

Dir 

2.0 

BOM 

motive 

Dir 

3.0 

BOM 

spice 

Dir 

2.0 

BOM 

verify 

Dir 

3.3 

BOM 

verilog 

BOM tools 




releasebom Make, commit, and release a BOM. This tool will 
release all the checked in components for the 
specified directory (default is 7) and all 
subdirectories (i.e. you release the directory tree 
rooted at the target directory). 

getbom Retrieves a BOM and extracts the contents specified by 
the BOM 

diffbom Shows the difference between two existing BOM files 
mkbom Makes a BOM file for the specific directory (used by 

releasebom - the normal user does not need to use this 

command). 

General Information 


Typical command sequence to release *new* files. 


cvs add file 1 file2 ... 

cvs commit filel file2 ... ** 

releasebom 
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** You will see later on there are shortcuts offered by the "commit' 
command that don't require you to type the names of the files 
you want to commit. Also, remember ' commit' and 'ci' are synonymous. 


Typical command sequence to release *modified* files. 


cvs commit filel file2 ... ** 
releasebom 

** You will see later on there are shortcuts offered by the "commit 1 
command that don't require you to type the names of the files 
you want to commit. Also, remember 'commit' and ci* are synonymous. 


How do 1 extract the contents specified by a BOM 


Suppose I wanted to extract the 'test' schematic found in proteus/ged/test 
according to BOM version 1 .4. Here are the steps. 

cd ~/proteus/ged/test # I assume the directory already 
# exists. If not, create it. 

If the directory 'test' is already under CVS control (i.e. there is a 

CVS directory present and so the location of the BOM can be determined 

automatically). 

getbom -r 1 .4 

Or, if the directory is not under CVS control (i.e. there is no CVS 
directory present) then you have to tell getbom where in the repository 
the BOM exists. 

getbom -r 1 .4 proteus/ged/test 

This will extract all the files and/or directories that are specified 
by BOM version 1.4. 


How do I get a specific file that is in the cvs repository? 


The following command will extract a specific file. 

cvs checkout proteus/ged/ca/cabyte/spice_cn. I . I 

This command will create a proteus directory (in the directory in which 
the command was executed), a ged directory within the proteus directory, 
a ca directory within the ged directory, a cabyte directory.... (I think 
you get the picture) and finally extract the specified file. 

The following command will extract an entire directory (in the same 
fashion as described above) except it will extract the entire 
directory tree (i.e. all files and subdirectories like cab it, 
cabitisrc, cabslds, cacasld, ...). 

cvs checkout proteus/ged/ca 

The following command will only extract all the files in the specified 
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directory (in the same fashion as described above). This would include 
the files Makefile, Makefile. Spice, README, startup.concept.base, and 
startup.ged.base if I was extracting the proteus/ged directory. 

cvs checkout -1 proteus/ged 


Once I have my files checked out, how do I update them to reflect any 
changes that may have occurred in the repository? 


cvs update filel file2 ... 

This command will either 

a. bring the specified files up-to-date 
with respect to what is found in the 
repository (i.e. no local mods) 

or 

b. merge any local modifications into 
the version found in the repository. 

*note* If there is a conflict during the merge, the 

*note* original file is saved as 

*note* 

♦note* .#filename.version 
*note* 

*note* in the current directory. 

cvs update -1 This command will perform the operation described 
above on all files in the local directory that 
are under CVS control. 

cvs update This command will perform the operation described 
above on all files in the local directory *and* 
all files in lower directories as well. 

cvs update -d The -d option will cause any new directories 
that have been added to the repository to also 
be extracted and updated. 

The -d option is very useful and can be done 
instead of using 'checkout' if you want to 
extract a directory that was previously excluded 
(or added to the repository) since the initial 
checkout. 


How do I find out the status of my local file? 


cvs status filel file2 ... 

Gives status information for each of the named files. 

cvs status -1 Gives status information for all files under CVS 
control in the current directory. 

cvs status Gives status information for all files under CVS 
control in the entire directory tree rooted at 
the current directory. 


What does using the CVS status command tell me? 
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Here is the output of the command: 

cvs status /u/chip/proteus/Makefile.defs 


File: Makefile. defs Status: Up-to-date 


Version: 1.51 Wed Feb 23 14:38:26 1994 

RCS Version: 1.51 /p/cvsroot/proteus/Makefile.defs,v 

Sticky Tag: (none) 

Sticky Date: (none) 

Sticky Options: (none) 

Here is a description of all the little bits of info. 

File: You guessed it, the file name. 

Status: This tells you all sorts of info about the status 

of the file. The following describes the different 

status reports. 

Up-to-date The local file is identical the that found 
in the repository. 

Locally Modified 

The local file is derived from the same 
version that is found in the repository, 
but is is modified. 


Needs Checkout The local file is an older version from 
that found in the repository. 

Needs Merge The local file is derived from an older 
version than what is currently found in 
the repository, *and* it has local changes. 

Locally Added The file is staged to be added to the 
repository on the next commit (or ci). 
This is the result of a 'cvs add' command. 


Locally Removed The file is staged to be removed from the 
repository on the next commit (or ci). 
This is the result of a 'cvs remove' command. 

Entry Invalid This means that since this file was checked 
out by you, someone else has used the 
'cvs remove' command to remove the file 
from the repository. A future 'cvs update' 
will cause this file to be removed from your 
working area too. 

Unresolved Conflict 

This means that there is a file found 
locally (currently *not* under CVS control) 
that has the same name as a file that *is* 
under CVS control. 


Unknown The file is neither added to the repository 
or is found in the repository. 
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Version: The version that the current file is derived from. 
RCS Version: The version of the file in the repository. 
Sticky Tag: This lets you ' attach' yourself to a specific 

version and will prevent you from getting any 

newer versions from the repository. 

This feature should only be used when a 'branch' 

is being used. 'Branches' will be described later. 
Sticky Date: This value is similar to what was described for 

a 'Sticky Tag' but in general we are not using this 

feature. 

Sticky Options: Same description as 'Sticky Date'. 

A useful alias that you might want to include in your shell startup 
files might be something like... 

alias status 'cvs status -I |& egrep File:' 

alias allstatus 'cvs status |& egrep "ExaminingjFile:"' 

The 'status' alias will give you the file name and status field for 
each of the file in the current directory. 

The 'allstatus' alias will the same information as status except it 
will include all the lower directory as well. 

(the '!&' means to put both stdout and stderr through the pipe) 


How do T cause a new directory xxschem in my existing checked out tree 
(~/proteus/ged/xx) to be added to the repository? 


What if this new directory also contains new files? 

cd ~/proteus/ged/xx Position yourself in the directory above 
the one you are about to add to the 
repository. 

cvs add xxschem CVS will ask if you really want to add 
this to the repository - the answer will 
be yes. 

* now the directory has been added to the repository * 

cd xxschem Enter the directory so we can add the new 

files. 

cvs add body* spice* Tell CVS that you want to add the specified 
files to the repository on the next 
commit. 

cvs commit This will commit all the files that have 

been modified, marked for addition, or 
marked for deletion in the current 
directory tree. 


Can 'cvs commit' figure out what to do by itself? 


Yes. Here are some examples, 
cvs commit This will commit all files that have been 
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modified, marked for addition, or marked 
for deletion in the entire directory 
tree. 

cvs commit -1 This will commit all files that have been 
modified, marked for addition, or marked 
for deletion in the current directory 
(not the entire tree). 

cvs commit filel fi!e2 ... 

This will commit any changes, staged 
deletions, or staged additions of the 
specified files. 


How do I Temove files from the repository. 


rm filel file2 ... Remove the files via a unix command first. 

cvs remove filel file2 ... 

Tell CVS that on the next commit, it 
should remove the named files from 
the repository. 

cvs commit filel file2 ... 

Commit the removal of the files from 
the repository, (cvs commit -1 may 
also have been used). 


If I 'cvs remove' and 'cvs commit' a file, is it gone forever? 


No. The file is actually moved into a directory in the repository 
called 'Attic'. This way you can still checkout a 'removed' file 
by using the '-r' option of update or checkout (-r lets you specify 
a specific revision number or tag). 

*NOTE* If you use the '-r' option to extract a specific version 
of a file, the Sticky Tag will be set. If you want 
to later extract the latest version from the repository 
you will need to use the 'cvs update -A' commmand that tells 
CVS to override any Sticky Tag found. 

If you want to reinstate a removed file, there is no automatic way 
for this to occur. Please give me a call and I will help you 
'un-remove* the file. 


How can I tell who made changes to a file? 


cvs log filename This command will list all the 
changes, the id of the person who 
made the changes, and the checking 
message that was supplied. This 
information is often quite lengthy 
so you may want to pipe it to 'more 1 . 
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How can I find out what is different between my existing file 
and the one found in the repository. 


cvs diff filename This command will run Miff using 
your local file and the file in 
the repository *with the same version*. 


cvs diff-rl 


.7 filename 

This command will run 'diff using your 
local file and the file in the repository 
with version '1.7'. 


cvs diff -rl 


.7 -rl.8 filename 

This command will run 'diff on versions 
1 1 .7* and ' 1 .8' of file name found in 
the repository. 


♦NOTE* there must not be a space between the '-r* and the version! ! ! ! 
(cvs diff actually uses 'rcsdiff which doesn't like spaces 
between the version and the '-r 1 ). 


How can I find out more info about these tools? 


There are man pages available for all the tools and I am always happy 
to answer any questions or help with any problems you might have. 


How can two people work on the same file most effectively? 


The cvs check-in/check-out process gives you interlocks, just not at 
the time that you check a schematic out. If two people are editing the 
same schematic at the same time, the first person who checks in their 
changes sees nothing different than normal. The second person, when 
attempting to check in their changes, is told (and prevented from 
checkin in) that their local copy is no longer up-to-date with 
respect to the repository and they need to 'merge' their changes (i.e. 
find out what the other person did and make sure it is incorporated 
properly into your local schematic) before the commit is allowed. 
In this case, you find out at 'commit time' that someone else was 
editing the schematic at the same time. 

The 'cvs status' command will tell you at any time if you are working 
on the most recent copy of a schematic. If you are working in an area 
were it is common to have two people editing schematics at the same time, 
it would be wise to check the status of your local copy (ensuring 
it it derived from the most recent version) before embarking on any edits, 
then committing the changes as soon after the editing is complete by 
using 'cvs commit'. This way the chances of collisions is reduced 
enormously. 

An example of this process would be: 

cvs status file # check status before I edit, 

edittoolofchoice file # make my changes 
cvs commit # commit my changes 

This previous sequence may be repeated may times over many days.... 
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releasebom 


# release it. 


What is a 'tag'? 


A "tag* is simply a symbolic name attached to a particular version of 
a file. It is possible to assign a tag to any or all files within a 
directory (or possibly subdirectories). 

cvs tag tagname 

Recursively assigns the symbolic tag 'tagname' 
to all the local sources. 

cvs tag symbolic_tag filename 

Assigns the symbolic tag 'tagname' to the 
specified file name only. 

To extract a file with a tag, use the '-r' flag with the update or 
checkout commands. 

cvs update -r tagname 

Recursively update all directories so that they 

contain only files with the given tag. 

This means all other files that do not have the 

specified tag will be deleted from your local 

version! 

cvs update -r tagname filename 

Extract the version of the specified file name 
that corresponds to the tag 'tagname'. 


How do I delete a tag? 


A tag may be removed by using the '-d' option with the 'cvs tag' 
command. 

Note: Be very careful when deleting a tag since this will effectively 
discard some historical information (i.e. a future extraction of the 
discarded tag will no longer include the file or files that had 
previously been marked with the tag). Do not remove a tag unless 
it is absolutely necessary. 

cvs tag -d tagname 

Recursively removes the symbolic tag 'tagname' 
from all the local sources. 

cvs tag -d tagname filename 

Same description as above except the tag is only 
removed from the specified file name. 


What is a 'branch'? 


A 'branch' provides the ability to commit changes to a given source file 
without requiring that the sources be up-to-date with respect to the 
latest revision of the file available on the 'trunk' (the main stream 
of development) but instead based on some previous version. 
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The use of a 'branch tag 1 allows concurrent isolated development. 
Typically this is used for creating a patch to a previously released 
component or to allow for an experiment or special development 
on a particular component independent of the main stream development. 
Later, if the experiment succeeds, that development work can be 
merged into the trunk. 


How do I create and use a branch tag? 


A branch may be created and used by using the '-b' (branch) option 
with the 'cvs tag' command and then checking out (or updating) 
the sources with the newly created tag. 

Note: You need assign a branch *and* extract the files based on the 
branch tag in order to properly use a branch. 

cvs tag -b branch_tag (step 1) 

Recursively assigns the symbolic tag 'branch_tag' 
to all the local sources. 

cvs update -r branch_tag (step 2) 

Checks out all the sources with the tag 'branch tag' 
and ensures that future commits are based upon 
this branch instead of forcing changes to be 
up-to-date with respect to the trunk. 

cvs tag -b branch_tag filename (step 1) 
cvs update -r branchjtag filename (step 2) 

Same function as described above but only with 

respect to the specified file name. 

Future commits that occur on files that have been extracted (using 
the checkout or update commands) with a branch tag will all be based 
upon the original version of the file when it was made a branch. 
Future development on the trunk and the branch will be concurrent 
and independent. 


What is the significance of the ' Sticky Tags' that I see when I 
use 'cvs status' of a file that is either a branch or has been tagged? 


Any time a file is committed or extracted with a specific revision number 
or symbolic tag, a 'Sticky Tag' is set. This tag allows future 
commit, update, or checkout commands to always be relative to 
the version associated with the sticky tag. 

To override a sticky tag you may use the '-A' option with the 
update or checkout commands. This option will cause CVS to forget 
about specific versions and instead reference the 'head' (newest 
versions available on the trunk) revisions. 


How to incorporate changes made to a branch into the truck? 


If the changes that have been made to a branch are also wanted 
in the trunk, you may use the '-j* option of the update command 
to merge changes from a specified tag into the trunk. 
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Note: You can not merge changes made on the mainline into a branch 
but you may instead merge changes from a branch into the mainline 
and you can also merge changes made in one branch into another. 

cvs update -j branchtag 

Recursively merge all changes made in the branch 
with the tag 'branchtag' with the current sources. 

There is a lot of stuff that I don't understand with regard to the 
use of the -j option. If you learn more, please teach me :-) 


ItlfHiffifi // /J t\ if If H H H ft fi if4i44iii4444i4i4i4444444i4i4i44444444^t^f^4^Ii 44-444444rM 41 44 44444444 4444414444 444444444444444444444444 444444 
44344444444444&444444444444441i&i£4i44#444t44444i&4i44l41ii4 

^######################################################################### 
Here is the README file 


The helper files Makefile. defs and Makefile. rules are analogous to the 
files of the same names in proteus — a typical tool Makefile would 
include Makefile. defs, then force some variable definitions, then 
include Makefile.rules. For example, a Makefile to install the shell 
script 'foo' and it's man page 'foo.l' would look like: 

CHIPROOT := $(shell abspath ../../..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

SCRIPTS = foo 
MANS = foo.l 

include $(CHIPROOT)/tools/src/Makefile.rules 

If a directory contains multiple shell scripts, they can simply be 
added to the end of the SCRIPTS definition, and their man pages added to 
the MANS definition (if you have no man pages, don't bother defining 
MANS). (For this simple case, 'gmake install-all' still does a build 
on every architecture. This doesn't hurt much, and I know how to fix 
it, but haven't gotten to it yet). 

If you have a C program (which can have a lex/yacc parser, as shown in 
this example), it's Makefile could be: 

CHIPROOT := $(shell abspath ../../..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

EXEC - prog 
SCRIPTS = prog 

SOURCES = progmain.c utils.c parser.y scanner.l 
REFLIBS = tusk octmisc 
MANS = prog. 1 

include $(CHIPROOT)/tooIs/src/Makefile. rules 
This assumes that the current directory contains the following files: 
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prog shell script wrapper for the program 

progmain.c a C source file 

utils.c another C source file 

parser.y the yacc parser 

scanner. 1 the lex scanner 

prog. 1 the man page 

The program will be linked with libtusk.a and liboctmisc.a (in that 
order), and the math library (I always add Mm' to the end of the link 
line). The token-definition file generated by yacc (which is normally 
included in the scanner) will be called 'parser.h'. Following the 
style I've developed, this Makefile will create the following hierarchy 
under the source directory: 

tools/src/prog/ 
sun4/ 
prog* 
parser, c 
parser.h 
scanner, h 
obj/ 

progmain.o 

utils.o 

parser.o 

scanner.o 

sgi/ 

(same as sun4) 
snake/ 

(same as sun4) 

Obligatory style comment: styles are fairly personal, and I won't make 
any attempt to convert people to this one. I like it because it 
separates the stuff for the different architectures and avoids 
cluttering the top level directory (this also means that you can say 
'cvs -n update' without being flooded with messages about derived 
files). If you prefer another style, I'm afraid you won't be able to 
use the Makefile.* I've set up. 

These Makefile.* files can also install libraries. Here's tusk's 
Makefile (there's actually a bit more fluff involved in implementing a 
test suite, but this is the meat): 

CHIPROOT := $(she1l abspath ../../..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

LIB - tusk 
HDRS = tusk.h 
MANS = tusk.3 

SOURCES = create .c queue.c byte.c reduce.c deferred.c accumx \ 
boolean.c grow.c transform. c partition. c \ 
box.c polygon.c edge.c grid.c printc memory.c 

REFLIBS = fang octmisc 

PRrNT_SRC := $(HDRS) tusk-int.h scan.h $(SOURCES) 

include $(CHIPROOT)/tools/src/Makefile. rules 

The HDRS macro lists header files to be installed in tools/include. 
The REFLIBS macro is only needed to support a target I didn't mention 
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before: if you say "gmake saber-tusk" it'll emit the commands to 
load the source files and any needed libraries. The PRINT_SRC macro is 
also only needed to support a target I didn't mention before: if you 
say "gmake printout" it'll format and print a copy of the source. 

The above examples only show a single library or executable being made 
and installed from one directory. If you have more than one of these, 
then you need to use the third helper file, Makefile. oneprog. This is 
because you need to define a different set of sources and reflibs for 
each. To show this, here's vlsimm's Makefile (again, with some testing 
fluff omitted). BTW, in the process of building these Makefile helpers, 
I suddenly found it was easy to do something Dan asked for a while ago: 
split out the vlsi I/O code as a separate library (which is now 
installed as libvlsi.a). 

CHIPROOT := $(shell abspath ../../..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

# 

# Build the vlsimm executable 

# 

EXEC = vlsimm 
SCRIPTS = vlsimm 

REFLIBS = $(ARCH)/Iibvlsimm.a $(ARCH)/libvlsi.a \ 

mebesout mebesread wap tusk octmisc udblib 
MANS - vlsimm. 1 

include $(CHIPROOT)/tools/src/Makefile,oneprog 

# 

# Build libvlsi.a 
# 

LIB - vlsi 
HDRS = vlsi.h 
SOURCES = vlsi.c 

include $(CHIPROOT)/tools/src/Makefile. oneprog 

# 

# Build libvlsimm.a 

# 

LIB = vlsimm 

SOURCES = vlsimm. c datasetx iovlsi.c iomebes.c feature.c instr.c \ 
maskmod.c optimize.c subcell.c squares.c maskout.c \ 
yacc.y lex.l 

PRINT_SRC:= vlsimm. h vlsi.h format.h maskout.h $(SOURCES) vlsix 

include $(CHIPROOT)/tools/src/Makefile.rules 

This Makefile installs two libraries and one executable. Note that the 
executable uses some libraries that are locally generated (and it gets 
them from the local area, so you can build the executable for testing 
without installing the libraries). There's some more flexibility here, 
primarily useful for testing: any entry in REFLIBS that ends in \a' is 
taken to be the unix path name of a library to be linked in; any other 
entry is taken to be the root name of a library that's installed in 
tools/lib/$(ARCH)/lib<name>.a. 
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Stuff that I know needs work: 

As noted above, a Makefile that doesn't have to compile anything 
should not rsh to each machine in BUILDJHOSTS to do an install. 

The man-page installation rule uses 'soelim', which doesn't exist 
on the sgi. This only causes trouble if an sgi machine is the first 
in the list of BUILD_HOSTS. 

There's no support for installing anything other than object 
libraries in tools/lib. 

There isn't much support for tools that can only be built on a 
subset of the available machine architectures. The one hack I put 
in is that if you define " ARCH := ." after including 
Makefile. defs, it won't do any rsh'ing, but will just build on the 
current machine (which presumably will always be a sun). In this 
case, the architecture subdirectory gets collapsed into the main 
tool source directory. 


Tom L. 
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From: Rich McCauley [rich@pegasusj 

Sent: Wednesday, October 26, 1 994 1 1 :21 AM 

To: 'woody @luckboy' 

Cc: 'ras@pegasus'; 'tbr@pegasus' 

Subject: Re: Expansion connector 

1 believe so, This pair of lines should be controlled impedance just like in 
the case of sending 54MHz from calliope to euterpe. 

rich 


> From woody@luckboy Wed Oct 26 08:05:34 1994 

> Date: Wed, 26 Oct 1994 08:05:20 -0700 

> From: woody@luckboy (Jay Tomlinson) 

> To: ras@luckboy, tbr@aphrodite (Tim B. Robinson) 

> Cc: hestia@luckboy 

> Subject: Re: Expansion connector 

> Content-Length: 2906 
> 

> Do these need to be isolate from other signals using GND in the same way as the 

> hermes channel? 

> 

> Tim B. Robinson wrote (on Mon Oct 24): 

> 

> Did the change to put a copy of the 54MHz reference on the expansion 

> connector get incorporated? That seems to be the preferred choice. 

> If not please get it into the next ECO. 

> 
> 

> Rich McCauley wrote (on Tue Oct 1 1): 

> 

> Options 1 & 3 are acceptable. Option 2 I don't like, given that the PLL for 

> Hermes isn't specifically optimized to allow cascading which this would be an 

> example of. That is, one needs to carefully control damping factor in the PLL 

> design to keep loop response peaking to very low levels if using the output to 

> provide a locking reference for another PLL. This was not a design criteria 

> for the Hermes loop since it is designed to work with DLLs which themselves 

> don't have a second order peaking response, 
> 

> Of option 1 or 3, 3 is certainly the most flexible and appealing from that 

> point of view. 

> 

> rich 

> 
> 

> > From tbr@aphrodite Mon Oct 1 0 20:3 1:09 1 994 

> > Date: Mon, 10 Oct 1994 20:30:49 -0700 

> > From: tbr@aphrodite (Tim B, Robinson) 

> > To: hestia@aphrodite 

> > cc: bill@aphrodite, ras@aphrodite 

> > Subject: Expansion connector 

> > Content-Length: 1275 

> > 

> > 
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> > The Hestia expansion connector currently only provides the second 

> > Hermes channel and the Cerberus clock and data lines. 

> > 

> > This gives us a potential problem in the expansion box if we come to 

> > implement a new device which connects to the Hermes channel. The only 

> > clock we have available is the clock which is part of the Hermes 

> > channel. We have a number of options. 

> > 

> > 1 . Restrict ouselves to devices which (like Mnemosyne) have everything 

> > clocked directly at the Hermes frequency. 

> > 

> > 2. Provide a programmable divider inside any expansion device to 

> > reconstruct the basic 54MHz reference frequency given knowledge of the 

> > Hermes clock rate, and use a PLL to multiply it back to the required 

> > rate. 

> > 

> > 3. Bring the existing 54HMz reference to the expansion connector. 

> > 

> > Of these, my preference is 3, but it may have a problem with adding a 

> > stub to the reference clock traces. However, we do have programmable 

> > termination which could be adjusted depending on whether an expansion 

> > device is present or not. 

> > 

> > We do not have the option of running the internals of any expansion 

> > device from a totally separate oscillator. To do so would introduce 

> > a synchronization hazard at the Hermes interface which would not be 

> > acceptable at the typical rate of operation. 

> > 

> > Comments please. 

> > 

> >Tim 

> > 

> > 

> > 

> > 

> > 

> > 
> 
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From: Eric Murray [ericm@MicroUriity.com] 
Sent: Wednesday, October 26, 1994 3:21 PM 
To: Tim B. Robinson' 
Subject: Re: Date on gaea wildly off 

Tim B. Robinson wrote: 

> 
> 

> Mark Hofinann wrote (on Wed Oct 26): 
> 

> 

> Hi, 

> 

> I noticed that the date on gaea is 04:59 when tomato says 06:43 

> 

> What's going on? 

> 

> It's a lot closer now, but there is still a significant discrepancy: 

> 

> tbr@gamorra ~/euterpe/verilog/bsrc/au 428 % rsh gaea date; date 

> Wed Oct 26 13:39:54 PDT 1994 

> Wed Oct 26 14:01 :30 PDT 1994 

ntp wasn't running for some reason; i've started it so 
it should sync up in a while. 


ericm ericm@microunity.com 
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From: 


tbr 


Sent: 


Wednesday, October 26, 1994 4:02 PM 


Subject: 


To: 


Cc: 


'Mark Hofmann' 
'sysadrr^tomato' 
Date on gaea wildly off 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Wed Oct 26): 
Hi, 

I noticed that the date on gaea is 04:59 when tomato says 06:43 

What's going on? 

It's a lot closer now, but there is still a significant discrepancy: 

tbr@gamorra ~/euterpe/verilog/bsrc/au 428 % rsh gaea date; date 
Wed Oct 26 13:39:54 PDT 1994 
Wed Oct 26 14:01:30 PDT 1994 


Tim 
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Subject: 


From: 
Sent: 
To: 


Cc: 


Loretta Guarino [guarino@thessalus.microunity.com] 
Wednesday, October 26, 1994 4:48 PM 

'gmo@thessalus.microunity.com'; 'wayne@thessalus.microunity.com'; 
'jeffm@thessalus.microunity.com'; 'doi@thessalus.microunity.com'; 
'sandeep@thessalus.microunity.com'; 'gregg@thessa I us. micro unity, com' 
'guarino@thessalus.microunity.com'; 'abbott@thessalus.microunity.com'; 
'lisar@thessalus.microunity.com'; 'hestia@thessalus.microunity.com' 
bring-up meeting of October 26 


Next meeting: Nov. 2 at 10:00 
Action items from last meeting: 


> Explore solutions for programing FlashROM from a 

> separate fixture, that is, without Euterpe code. 

> (Wayne) 

Done. We are currently waiting on vendors. 

> Define parallel interface. (Wayne, Gmo, and Sandeep) Due by the end of October. 
There will be a meeting on Friday on this topic. It was determined that we do still need a 
parallel interface, since Pandora will not be available soon enough to use in bringing up 
Hestia. 

> Implement parallel port device drivers for sun and 

> sgi. (Sandeep and Derek) 

No progress. Waiting for parallel interface definition. 

> Investigate what hardware support isneeded to run 

> tests from different locations (e.g. buffer, ROM, 

> RAM, Cerberus) (Jeff, Wayne) 

Done. Jeff and Wayne added one level, with and without phase lock loops. 

> Define the boot state for standalone tests (Jeff, Gmo) Mostly done. Jeff will update 
the current proposal and circulate it. 

> Write up a plan for virtual devices and their 

> interaction with gdb (Gmo) 
No progress. 

=> Build scripting/UI capabilities above gdb for 

> regression tests (Derek) 

This work depends on the availability of a remote gdb that works with the Microkernel on 
terp. Derek estimates he will need 1 additional week to produce an initial system. 

> Create a separate tool for loading FlashROM 

> (Unas signed) 

No progress [manufacturing issue] . 

> Implement remote gdb with the software simulator 

> (Sandeep) 

A version of remote gdb working with the Microkernel is expected by Nov. 6. Sandeep 
estimates another 2 weeks to develop a general stub to enable remote debugging of 
standalone tests, but will have a better estimate after he completes the Microkernel 
version. 

> Find out who is driving the characterization testing 

> of components, especially for Euterpe. (Loretta) No progress. 

> Identify changes needed to Wayne's Bring-up plan 

> for Verification (Wayne, Jeff) 
See discussion below. 

> Develop set of milestones and schedule for bring -up 
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> (Wayne, Derek, Loretta) 
We worked out some rough milestones through hardware bring-up and non- realtime software. 
Derek will add these to the Bring-up plan. 

New items : 


Additional changes and additions to the Bring- up plan: 

1. Derek has merged the MediaCom bring-up plan with Wayne's 
bring- up plan. 

2. The Verification group's test control document will be 
added to the bring-up plan. 

3 . Jeff will write a summary of the hardware bring-up 
process, more in the style of the MediaCom plan. We can 
then compare this with Wayne's schedule to see if we 
have the same model of what happens when. This will then 
be added to the plan. 

4. We need to identify our bring-up tools and make sure we 
have plans for how we will debug them. Wayne's plan 
contains a list of hardware tools; Derek has agreed to 
collect the list of software tools from everyone 
involved, and add this list to the plan. We all need to 
review Wayne's list, as well as sending information to 
Derek. 

Testing real-time software: ensure that the mediacom tests like the benchmark will work 
even if we cannot provide high-speed input and output; develop a plan for providing high- 
speed channels before Calliope is completely debugged. 
(Gregg) 

Verify SN3 . (Wayne) 
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From: Loretta Guarino [guarino@MicroUnity.com] 

Sent: Wednesday, October 26, 1 994 4:48 PM 

To: 'gmo@MicroUnity.com'; 'wayne@MicroUnity.com'; 'jeffm@MicroUnity.com'; 

'doi@MicroUnity.com'; 'sandeep@MicroUnity.com'; 'gregg@MicroUnity.com' 
Cc: 'guarino@MicroUnity.com'; 'abbott@MicroUnity.com'; 'lisar@MicroUnity.com'; 

'hestia@MicroUnity.com' 
Subject: bring-up meeting of October 26 


Next meeting: Nov. 2 at 10:00 
Action items from last meeting: 


> Explore solutions for programing FlashROM from a 

> separate fixture, that is, without Euterpe code. 

> (Wayne) 

Done . We are currently waiting on vendors . 

> Define parallel interface. (Wayne, Gmo, and Sandeep) Due by the end of October. 
There will be a meeting on Friday on this topic. It was determined that we do still need a 
parallel interface, since Pandora will not be available soon enough to use in bringing up 
Hestia. 

> Implement parallel port device drivers for sun and 

> sgi. (Sandeep and Derek) 

No progress. Waiting for parallel interface definition. 

> Investigate what hardware support isneeded to run 

> tests from different locations (e.g. buffer, ROM, 

> RAM, Cerberus) (Jeff, Wayne) 

Done. Jeff and Wayne added one level, with and without phase lock loops. 

> Define the boot state for standalone tests (Jeff, Gmo) Mostly done. Jeff will update 
the current proposal and circulate it. 

> Write up a plan for virtual devices and their 

> interaction with gdb (Gmo) 
No progress. 

> Build scripting/UI capabilities above gdb for 

> regression tests (Derek) 

This work depends on the availability of a remote gdb that works with the Microkernel on 
terp . Derek estimates he will need 1 additional week to produce an initial system. 

> Create a separate tool for loading FlashROM 

> (Unas signed) 

No progress [manufacturing issue] . 

> Implement remote gdb with the software simulator 

> (Sandeep) 

A version of remote gdb working with the Microkernel is expected by Nov. 6. Sandeep 
estimates another 2 weeks to develop a general stub to enable remote debugging of 
standalone tests, but will have a better estimate after he completes the Microkernel 
version. 

> Find out who is driving the characterization testing 

> of components, especially for Euterpe. (Loretta) No progress. 

> Identify changes needed to Wayne's Bring-up plan 

> for Verification (Wayne, Jeff) 
See discussion below. 

> Develop set of milestones and schedule for bring-up 

> (Wayne, Derek, Loretta) 
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We worked out some rough milestones through hardware bring-up and non-realtime software. 
Derek will add these to the Bring-up plan. 

New items : 


Additional changes and additions to the Bring-up plan: 

1. Derek has merged the MediaCom bring-up plan with Wayne's 
bring-up plan. 

2. The Verification group's test control document will be 
added to the bring-up plan. 

3 . Jeff will write a summary of the hardware bring- up 
process, more in the style of the MediaCom plan, we can 
then compare this with Wayne's schedule to see if we 
have the same model of what happens when. This will then 
be added to the plan. 

4 . We need to identify our bring- up tools and make sure we 
have plans for how we will debug them. Wayne's plan 
contains a list of hardware tools; Derek has agreed to 
collect the list of software tools from everyone 
involved, and add this list to the plan. We all need to 
review Wayne's list, as well as sending information to 
Derek. 

Testing real-time software: ensure that the mediacom tests like the benchmark will work 
even if we cannot provide high-speed input and output; develop a plan for providing high- 
speed channels before Calliope is completely debugged. 
(Gregg) 

Verify SN3 . (Wayne) 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Lisa Robinson [lisar@rhodan] 
Wednesday, October 26, 1994 5:45 PM 
'Loretta Guarino' 

'abbott@microunity.com'; 'doi@microunity.com'; 'gmo@microunity.com'; 
'gregg@microunity.com'; 'guarino@microunity.com'; 'hestia@microunity.com'; 
'jeffm@microunity.com'; 'sandeep@microunity.com'; 'wayne@microunity.com' 
bring-up meeting of October 26 


Loretta Guarino wrote (on Wed Oct 26) : 


> Find out who is driving the characterization testing 

> of components, especially for Euterpe. (Loretta) 


The characterization testing of our individual components is driven by Mudges' group. 
The characterization of individual components other than our components (ie do they meet 
their spec) is not (to my knowledge) being widely done, only as pertaining to the use in 
the product . 

The characterization of all components as they function in the Hestia product is being 
driven by Wayne, but specified and executed by the design groups. 


Lisa R. 
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From: 
Sent: 
To: 

Subject: 


Loretta Guarino [guarino@MicroUnity.com] 
Wednesday, October 26, 1994 8:25 PM 

'mediacom-software@MicroUn ity.com'; Vandyke@MicroUnity.com' 
automatic regression notification 


By popular demand, I am setting up a script to notify people of apparent regression 
failures. People will be notified if, for any reason, a test's PASS ED /FAILED results don't 
match the expected results in the master files. 

You will then have to look in the regression logs for more information about what failed, 
and why. 

Here is the current notification list; please let me know if you want to be added to (or 

removed from) any of these 

lists: 

N0TIFY_ACCEPT= " guar ino " 
N0TIFY_AUDI0= " guarino khp " 
N0TIFY_TV=" guarino brendan fur gregg" 
N0TIFY_DEMUX= "guarino gregg brendan" 
NOT I FY_KERNEL= "guarino fambro sandeep khp" 
N0TIFY_UTIL= " guarino gregg " 
N0TIFY_VIDE0= "guarino fur" 
NOTIFY_CALLIOPE= "guarino khp " 
N0TIFY_DSP=" guarino khp" 
N0TIFY_PH=" guarino claseman vandyke" 

Kevin Fambro is looking at ways to make the failure analysis a bit more intelligent and 
informative. In the meantime, this should ensure that people know as soon as any test 
result changes . 

If the expected result of a test changes, please feel free to edit /a/sof t/stb/test- 
data/regress . terp. master 

or /a/sof t/stb/test-data/regress . terp .master . 
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From: 
Sent: 
To: 

Subject: 


Lisa Robinson [lisar@nosferatu] 

Wednesday, October 26, 1994 11:17 PM 

'pandora@nosferatu' 

Re: Building the Pandora Schedule 


Revised times and dates based upon your feedback. 


Lisa R. 


In order to put together a comprehensive Pandora schedule I would like to call a series of 
focussed meetings to identify all of the tasks to be accomplished, their dependancies and 
estimated durations given current resources . 

This will be followed by an integration of these tasks lists into an overall Pandora 
schedule . 

The following will be discussed in separate meetings: 

1. Mnemosyne design and verification through to tested 
packaged parts. 

2. System level architecture through board level design. 

3. System software development, System hardware verification, 
System software verification. 

4. System mechanical and electrical design. 

5 . System bringup - here we may need to start by reviewing the 
current hestia bringup schedule. 

6 . Foundry Euterpe . 

The initial meetings will be held over the next week in the engineering conference room: 

1. Thursday (10/27) - 1.30 - 3.00pm 

2. Friday (10/28) - 1.00 - 2.00pm 

3. Monday (10/31) - 1.3 0 - 3.00pm 

4. Monday (10/31) - 10.30 - 12.00pm 

5. Thursday (11/3) - 11.00 - 12.3 0pm 

6. TBD 

Follow up meetings will be scheduled at the end of each meeting. 
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From: Lisa Robinson [lisar@nosferatuJ 

Sent: Thursday, October 27, 1 994 1 0:50 AM 

To: 'staffers@nosferatu'; 'jt@nosferatu'; 'hopper@nosferatu' 

Subject: Schedule meeting action items 


Action items from this weeks schedule meeting 

Hopper Geert requires CAD help for euterpe route 

Tbr Will go with event daemon definition as per last discussions. 
Tbr to send out decision mail. 

Graham Hestia signal integrity experiments need to be performed. 

Gmo Need a register file commit trace from Terp for logic 
verification and performance tracing. 

Gmo Definition of gf instruction. 
DONE 

Craig Needs to confirm the cerberus power on defaults for Euterpe. 

Van Dyke Understand why the compiler is generating exception 9 T s. 

Tbr Do we need to implement Mnemosyne tester mode? 

Tbr Talk to Johnny regarding tester synchronization for Hermes 
channel clock 

DONE 

Mouss JT needs to discuss budget with you. 

Mouss Geert has the foundry selection as a critical dependency in 
implementing the CMOS Euterpe. 

Lisar Mediacom and System software require closure on definition of 
the Parallel Cerberus Interface. 

Tony Investigate the high end test equipment /developers platforms 
et al market that could be satisfied by Pandora. 

Action items from the previous schedule meetings. 

??? Van Dyke needs NFS for Windows 3.5 - ??? 

Mudge To call a meeting regarding reliability testing and burn in of 
chips 

- DONE 

Ramos To call a meeting regarding reliability testing and burn in of 
Hestia " - STILL 

OPEN 

Mouss Curtis need office space - STILL 

OPEN 

Curtis Should include shorter term milestones with dates on his slide 

- DONE 

H? Should the TV guide be scheduled with a view to demoing it on 
an SGI in November? - ??? 

Graham To check with Rich on the pll baseplate completion date - DONE 
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Mudge/ Jt 1 s group needs the SDRAM and other power dissipation numbers 

Graham next week. - DONE 

Buck/ Need a PO for another compressor. - DONE 

Ann 

Mouss Ann needs to discuss stepper focus? - DONE 

Graham Channel 3/4 modulation is at least 10% o the available machine 

cycles. Is this the right way to go? Graham to call meeting. 

STILL 

OPEN? 

Graham/Curtis ISDN product realization should be planned for. 

Curtis may need more headcount . Should plan for shipment of 
30,000 ISDN mediacomputers during the first 6 months of next 
year . DOING? ? 
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From: vant [vanthof@hestia] 

Sent: Thursday, October 27, 1 994 1 1 :39 AM 

To: 'Mark HofmanrV; 'Geert Rosseel'; Tom Vo'; 'Tim B. Robinson'; 'Lisa Robinson' 

Cc: 'Dave Van't Hof 

Subject: euterpe metals drc 


The euterpe baseplate metals drc finished and is clean. This doesn't really mean anything 
for the baseplate layers, but it does indicate that the custom blocks are still okay for 
metals . 

Of course, the latest sdec/emitter coverage issue will change the 'metal' 
layers somewhat . 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std disclaim. h> 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 27, 1994 1:41 PM 

'jeffm'; 'doi' 

Re: terp questions 


> Register- commit traces will be needed - doi has been tasked with 
tracking 

> performance deviations between terp and the hw - and he will be coming 
to 

> bother you. 

Can you please specify what information you want in the register trace? 

In the absence of such info, I would say register number, value, and timestamp. But I 

wanted to check that there wasn't something else needed. 


thanks , 
lisa 
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From: tbr 

Sent: Thursday, October 27, 1 994 2:23 PM 

To: 'Eric Murray' 

Cc: 'hopper' 

Subject: Re: Date on gaea wildly off 

Follow Up Flag: Follow up 

Flag Status: Red 


Eric Murray wrote (on Wed Oct 26): 

Tim B. Robinson wrote: 

> 
> 

> Mark Hofmann wrote (on Wed Oct 26): 
> 

> 

> Hi, 

> 

> I noticed that the date on gaea is 04:59 when tomato says 06:43 

> 

> What's going on? 

> 

> It's a lot closer now, but there is still a significant discrepancy: 

> 

> tbr@gamorra ~/euterpe/verilog/bsrc/au 428 % rsh gaea date; date 

> Wed Oct 26 13:39:54 PDT 1994 

> Wed Oct 26 14:01 :30 PDT 1994 

ntp wasn't running for some reason; i've started it so 
it should sync up in a while. 

Thanks. Looks a lot better now! 
Tim 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 27, 1994 5:31 PM 
'software-checkins-dist' 
stb/include/terp tgcc_builtins.h 


Update of /p/cvsroot/ stb/include/terp 

In directory calliope : /usr/people/lisa/src/stb/include/terp 

Modified Files: 

tgcc_builtins . h 
Log Message: 

Put the copyswapi's inside the protective outer #ifdef, and made them macros so they don't 
depend on inlining and/or optimization. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Thursday, October 27, 1994 5:38 PM 

'euterpe@clio' 

'cadettes@clio'; 'Paul Poenisch*; Thomas Laidig' 
IMMINENT DECISION: atom change 


Well, we're trying to finalize the euterpe baseplate, so in keeping with tradition this 
seems like the time to change the atom. . . 

Seriously, I _am_ suggesting a slight atom change, which technically does not affect any 
baseplate layers. The change I propose is to remove the SDEC "halo 1 around the atom 
(consistent with the atom's disposition, this halo is broken into 3 pieces). This SDEC 
geometry was originally put into the atom when we planned to have the SDEC layer fixed in 
the baseplate, and it was felt that having some straps available for jumpers would be 
desirable. Since we decided to allow SDEC to be programmed in a "metal change' (over a 
year ago) , this argument no longer holds, and the presence of the SDEC in all atoms 
increases capacitance slightly and increases (again slightly) the chance of SDEC shorts if 
some small SDEC isolation feature doesn't get manufactured correctly. More importantly, 
it contributes to some structures at the edges of sofa areas where it is difficult to 
synthesize an effective SDEC isolation mask. 

I have checked all xb* , ea*, and sc* cells, and all other sofa cells for which we 
currently build gards models. The only cells I found that use this SDEC are 

scsynchll 
cged 

iosynchll 
ealnf 20s6x3a 

Of these, I believe ""cged 1 and "iosynchll' are obsolete ("cged' also only uses SDEC in 
parallel with much lower-resistance metal connections) . The desired SDEC can easily be 
drawn into "sccynchll"; "ealnf 20s6x3a ' uses an SDEC path to carry what looks like 1mA of 
current, which is a bad idea anyway, and I think needs to be fixed for electrical reasons. 

I have not checked anything else that may use the eel atom, but it seems clear that the 
use of this SDEC is quite rare. 

So here • s what I propose : 

I'll remove the SDEC from the atom, and some little plugs of SDEC 
that appear in some hemming cells strictly to satisfy SDEC design 
rules at the edges . 

I'll patch "scsynchll' and "ealnf 20s6x3a ' . 
Solo's periodic DRC/LVS runs will check up on me. 
I'll take the action to fix anything this might break. 


Since this should be done quickly if it's going to be done at all, I'd like to make this 

decision final and do my edits on Monday Oct 31. 

Objections? 


Tom L 


Exhibit C7 


Page 602 of 703 


From: Kurt Wampler [wampler@thoas] 

Sent: Thursday, October 27, 1994 5:56 PM 

To: 'euterpe@clio'; 'tom@clio' 

Cc: 'cadettes@clio'; 'paulp@clro' 

Subject: Re: IMMINENT DECISION: atom change 


Tom writes: 


>I have checked all xb* , ea* , and sc* cells, and all other sofa cells 
>for which we currently build gards models. The only cells I found that 
>use this SDEC are 
> 

> scsynchll 

> cged 

> iosynchll 

> ealnf2 0s6x3a 
> 

>0f these, I believe "cged' and "iosynchll' are obsolete {"cged" also 
>only uses SDEC in parallel with much lower-resistance metal 
>connections) . The desired SDEC can easily be drawn into "sccynchll • ; 
>"ealnf20s6x3a ' uses an SDEC path to carry what looks like 1mA of 
>current, which is a bad idea anyway, and I think needs to be fixed for 
>electrical reasons. 

Oopsl cged is the final clock driver used in the Euterpe clock spars. 
It will need to be brought up-to-date with this change. 

- Kurt 
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From: john mudge [mudge@hera] 

Sent: Thursday, October 27, 1994 6:01 PM 

To: 'euterpe@clio T ; 'tom@clio' 

Cc: 'cadettes@clio'; 'paulp@clio' 

Subject: Re: IMMINENT DECISION: atom change 


> Since this should be done quickly if it's going to be done at all, I'd 

> like to make this decision final and do my edits on Monday Oct 31. 

> Objections? 


> Tom L 

Does this change, help or hinder, the difficulties we are experiencing in the fab. with 
the SDEC isolation mask which I believe involves the SDEC mask? 

j ohnnymudge 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Thursday, October 27, 1994 6:02 PM 

'Kurt Wampler' 

'euterpe@clio\ 'cadettes@clio'; 'paulp@clio'; Thomas Laidig' 
Re: IMMINENT DECISION: atom change 


Kurt Wampler writes: 
Tom writes : 


>I have checked all xb* , ea*, and sc* cells, and all other sofa cells 
>for which we currently build gards models. The only cells I found 
>that use this SDEC are 
> 

> scsynchll 

> cged 

> iosynchll 

> ealnf20s6x3a 
> 

>Of these/ I believe "cged 1 and "iosynchll 1 are obsolete ("cged' also 
>only uses SDEC in parallel with much lower-resistance metal 
connections) . The desired SDEC can easily be drawn into "sccynchll • ; 
>"ealnf 2 0s6x3a' uses an SDEC path to carry what looks like 1mA of 
>current, which is a bad idea anyway, and I think needs to be fixed for 
>electrical reasons. 

Oopsi cged is the final clock driver used in the Euterpe clock spars. 
It will need to be brought up-to-date with this change. 

Oh, yeah, I got my names mixed up. Anyway, I don't think there's really any change 
necessary (although I'd remove the orphaned contact pedestal for cleanliness), since all 
the SDEC does is parallel metal (the SDEC resistance is about 5 0 ohms, while the metal 
resistance is like 0.8 ohms, so I don't think we'll notice the difference). 


Tom L 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Thursday, October 27, 1994 6:08 PM 

'john mudge' 

'euterpe@c!io'; 'cadettes@clio'; 'paulp@clio' 
Re: IMMINENT DECISION: atom change 


john mudge writes: 


> Since this should be done quickly if it's going to be done at all, 

> I'd like to make this decision final and do my edits on Monday Oct 31. 

> objections? 


> 


Tom L 


Does this change, help or hinder, the difficulties we are experiencing 
in the fab. with the SDEC isolation mask which I believe involves the 
SDEC mask? 

It helps solve that problem (and was precipitated by that problem) . We think we have the 
rudiments of a general solution to the SDEC isolation problem (there is no "SDEC ' mask per 
se, it's the * SDEC isolation' mask), which involves selectively growing small SDEC 
isolation features. In some cases, such as some of the sofa edges, this results in min- 
spacing violations on the SDEC isolation mask. 

This proposed change doesn't by any means fix the SDEC isolation problems, but it gets a 
bit of the junk out of our hair, and seems to have very little downside. 


Tom L 
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Subject: 


Sent: 

To: 

Cc: 


From: 


John Campbell [solo@echidna] 
Thursday, October 27, 1994 6:37 PM 
Tom Laidig' 

'euterpe@clio'; 'cadettes@clio'; 'paulp@clio'; 'tom@clio' 
Re: IMMINENT DECISION: atom change 


as Tom Laidig was saying 

scsynchll 
cged 

iosynchll 
ealnf20s6x3a 

i am still checking cged scsynchll and ealnf2 0s6x3a. iosynchll is definitely obso. 


..Of these, I believe "cged' and "iosynchll 1 are obsolete Ccged' also ..only uses SDEC in 
parallel with much lower-resistance metal ..connections). The desired SDEC can easily be 
drawn into " sccynchll ' ; . . "ealnf 20s6x3a ' uses an SDEC path to carry what looks like 1mA of 
..current, which is a bad idea anyway, and I think needs to be fixed for ..electrical 
reasons . 

I'll patch "scsynchll 1 and "ealnf 20s6x3a ' . 
Solo's periodic DRC/LVS runs will check up on me. 


only on the custom blocks . my run fires off at 00:05. BTW 


regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday, October 27, 1 994 7:00 PM 

To: *geert@rhea' 

Subject: pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/es BOM 61.0 initiated by dickson completed @ Thu Oct 2 7 
16:59:18 PDT 1994 with exit status 1.. chip 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, October 27, 1994 8:13 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/ src/gnu-tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

- Preserve *all* tag bits when written/read, even those that would normally make no sense. 

- When REALLY_ACCURATE_S IMULATION , keep a real (separate data) dcache . 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Thursday, October 27, 1 994 9:30 PM 

To: 'dickson@nosferatu'; 'mws@nosferatu'; 'veena@nosferatiT 

Cc: 'tbr@nosferatu'; 'jeffm@nosferatu' 

Subject: forwarded message from Lisa Robinson 


Finally finished! 
(From the top level) 
Lisa R. 


Start of forwarded message 

Return-Path: <lisar@nosferatu> 

Received: from nosferatu.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA 12596; Thu, 27 Oct 94 19:27:46 PDT 
Received: from iocalhost by nosferatu.microunity.com (8.6.4/muse-sw.2) 

id TAA 13334; Thu, 27 Oct 1994 19:27:45 -0700 
Message-Id: <199410280227.TAA1 3334@nosferatu.microunity.com> 
From: lisar@nosferatu (Lisa Robinson) 
To: lisar@nosferatu 

Subject: z_euterpe_wrap regression results - 251094.10451 
Date: Thu, 27 Oct 1994 19:27:45 -0700 


Design Name: z_euterpe_wrap 
Run Date: 251094 
Run ID: 10451 


Using BOM: 

Version BOM,v 157.nb 157.0 + nbfix 1994/10/24 12:49:58 LT woody 
Warning: Local BOM is out of date: 
File: BOM Status: Needs Merge 

Version: 157.0 Mon Oct 24 18:45:21 1994 

RCS Version: 157.2 /u/chip/chip-archive/euterpe/verilog/bsrc/BOM,v 
Sticky Tag: (none) 
Sticky Date: (none) 
Sticky Options: (none) 


Simulator: z_euterpe__wrap.mif.mm was built on Mon Oct 24 22:58:54 1994 
Run started on host: nosferatu at: Tue Oct 25 1 1:02:01 PDT 1994 
dpgmuladspc8_0 Ran ok 
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dpgmuladspcl6_0 Ran ok 
dpgmuladspc32_0 Ran ok 
dpgmuladspc64_0 Ran ok 
dpgmulspc8_0 Ran ok 
dpgmulspcl6_0 Ran ok 
dpgmulspc32_0 Ran ok 
dpgmulspc64_0 Ran ok 
dpgumu ladspc8_0 Ran ok 
dpgumu ladspc 1 6_0 Ran ok 
dpgumuladspc32_0 Ran ok 
dpgumu ladspc64_0 Ran ok 
dpgumulspc8_0 Ran ok 
dpgumulspcl6_0 Ran ok 
dpgumu1spc32_0 Ran ok 
dpgumulspc64_0 Ran ok 


- End of forwarded message 
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From: Buffalo Chip [chip@ghidra] 

Sent: Friday, October 28, 1994 12:33 AM 

To: 'geert^ghidra' 

Subject: output of euterpe/verilog/bsrc/ctiod/. checkoutrc 


Thu Oct 27 22:26:35 PDT 1994 (geert Thu, 27 Oct 1994 22:26:22 -0700} 
euterpe/verilog/bsrc/ctiod 

[Release BOM (V7.0) in euterpe/verilog/bsrc/ctiod (Thu Oct 27 22:26:35 PDT 1994)] 


Dir 

euterpe/verilog/bsrc/ctiod 

1.1 

. checkoutrc 

1.4 

Makefile 

1.2 

clean-request 

1.2 

ctiod.V 

6.1 

ctiod. ut 

1 . 2 

ctiodtester .V 

6.1 

ctiodtester . h 

2.2 

ctrasel .pla 

3.2 

ctwasel .pla 

1.2 

ctwe . Veqn 

1.1 

genpim . pi 

1.3 

genptab.pl 

1.3 

pimlib.pl 


===> running euterpe/verilog/bsrc/ctiod/ . checkoutrc (Thu Oct 27 22:26:42 PDT 1994) <=== 
gmake : "clean 1 is up to date. 
# 

# turn off pgroute 
# 

[ -f gards/nopgroute ] j ( touch gards/nopgroute # # use padtiles # [ -f gards/usepadtiles 
] | | touch gards/usepadtiles # # use pifpack # [ -f gards/usepifpack ] | | touch 
gards/usepifpack # # insert an instance of the clock tree # [ -f gards/addclock ] | | touch 
gards/addclock # # disable old dcell placement obstruction # [ -f gards/noobs ] | | touch 
gards/noobs # # now do it . . . 
# 

gmake GARDS_DISPLAY=clio : 0 . 0 gards/ctiod- iter 
gmake [1] : Entering directory 

* /N/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod 1 

cat /n/auspex/slO/chip/euterpe/proteus/verilog/dxlib/xlib. conf ig 

/n/auspex/slO/chip/euterpe/proteus/verilog/dclib/clib. conf ig 

/n/auspex/slO/chip/euterpe/proteus/verilog/delib/elib. conf ig > gards/ctiod. v2e . conf ig tt # 
Take a snooze to make sure vfiles looks older than the .v2e file # when they are on 
different NFS file systems # sleep 10 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/sl0/chip/euterpe/tools/bin/v2e -host ghidra -f vfiles -o gards/ctiod. v2e -c 
gards/ctiod. v2e . conf ig -1 gards/ctiod . v2e . log -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/mlib +libext+.v -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/dxlib -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/dclib -y 
/n/auspex/slO/chip/euterpe/proteus/verilog/delib 
V2E 1.0a Oct 27, 1994 22:27:14 

* Copyright Cadence Design Systems Inc. 1990. * 

* All Rights Reserved. Licensed Software. * 

* Confidential and proprietary information which is the * 

* property of Cadence Design Systems Inc. * 
Compiling source file " ctiod. v" 

Compiling source file " ctrasel. v" 
Compiling source file " ctwasel. v" 
Compiling source file "ctwe.v" 
Scanning library directory 

" /n/auspex/slO/chip/ euterpe/proteus/verilog/mlib" 
Scanning library directory 

"/n/auspex/slO/chip/euterpe/proteus/verilog/dxlib" 
Warning! library directory 

" /n/auspex/slO/chip/euterpe/proteus/verilog/dclib 11 was specified but not needed. 
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Warning! library directory 

"/n/auspex/slO/chip/euterpe/proteus/verilog/delib" was specified but not needed. 

Highest level modules: 

ctiod 

Reading configuration file gards/ctiod. v2e . config .... 
Processing configuration file .... 
Translating Verilog source .... 
Writing output to gards/ctiod. v2e .... 
0 warnings 0 errors 

End Of V2E 1.0a Oct 27, 1994 22:27:33 
CHI PROOT= /n/auspex/ s 1 0 / chip/ eut erpe 

/n/auspex/slO/chip/euterpe/tools/bin/emerge -f -R -p gards/ctiod. emerge . tab -e 
gards/ctiod. v2e -o gards/ctiod . edif -O gards/ctiod. emerge . log -I . . /cg/cgclockbias . v2e 
cgclockbias 

Running emerge compiled on Thu Oct 27 04:08:44 GMT 1994 

Consuming edif file gards/ctiod. v2e 

Found edif structure: CTlOD_46_V2E 
Flattening edif; 

flattened 151 instances; created 34 nets in CTIOD_4 6__V2E 

Reading Edif file for instance placement: . . /cg/cgclockbias . v2e 
Consuming power table information file gards/ctiod. emerge . tab 
Performing Edif Transformations... 
Warning! Port phi_A2P already top level. 
Warning! Port phi__B2P already top level. 
Disgorging edif file gards/ctiod . edif 

Writing edif structure: gards_4 7_ctiod_4 6_edif Memory usage: 1.488MB # # Get an 
initial sdl file. A manhattan approximation will be used # gmake GARDS_DISPLAY=clio : 0 . 0 
CYCLETIME=895 gards/ctiod-pass2 . sdl 
gmake[2]: Entering directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod 1 
CHIPROOT= /n/auspex/ slO/ chip/euterpe 
/n/auspex/ slO/chip/euterpe/tools/bin/topt -p 

/n/auspex/slO/chip/euterpe/proteus/misc/power . tab -p gards/ctiod. power . tab. local \ 

-h /n/auspex/slO/chip/euterpe/proteus/leaf gen/dcload/dcload. lib -h 
/n/auspex/ slO/chip/euterpe/proteus/exlax/dcload/dcload . lib -h 
/n/auspex/ slO/chip/euterpe/proteus/custom/dcload/dcload. lib \ 

-g /n/auspex/slO/chip/euterpe/proteus/leafgen/toptList -g 
/n/auspex/slO/chip/euterpe/proteus/exlax/toptList -g 
/n/auspex/ slO/chip/euterpe/proteus/custom/toptList \ 

-A /n/auspex/slO/chip/euterpe/proteus/leafgen/caps/cap . lib -A 
/n/auspex/ slO/chip/euterpe/proteus/exlax/caps/cap .lib -A 
/n/auspex/ slO/chip/euterpe/proteus/custom/caps/cap .lib \ 

-H /n/auspex/slO/chip/euterpe/proteus/leafgen/time/tim. lib -H 
/n/auspex/slO/chip/euterpe/proteus/custom/time/tim. lib -H 
/n/auspex/slO/chip/euterpe/proteus/exlax/time/tim. lib \ 

-1 895 \ 

-e gards/ctiod. edif \ 

-k gards/ctiod-passl . strength \ 

-B gards/ctiod-passl . sdl \ 

-s gards/ctiod-passl . stat \ 

-O gards/ctiod-passl . topt . log \ 

-z 2 -M mobimos -R -t 50 -b 10 -a 24 -0 -F 

Running topt (Timing OPTimizer) compiled on Thu Oct 27 04:08:01 GMT 1994 

Processing a: Mobimos, Flop/Latch design 
Consuming edif file gards/ctiod . edif 

Found edif structure: gards_4 7_ctiod_4 6__edif 
Flattening edif; 

CTIOD already flat. 

found 152 instances; found 606 nets in gards_47_ctiod_4 6_edif 
Consuming power table information file 
/n/ auspex/ si 0 /chip/euterpe/proteus /misc /power . tab 

Consuming power table information file gards/ctiod. power . tab. local 
Reading Stats file 
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/n/auspex/slO/chip/euterpe/proteus/leaf gen/stats . eel 

Reading Stats file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/stats . cmos 

Reading Stats file /n/auspex/slO/chip/euterpe/proteus/exlax/stats . ea 

Reading Stats file 
/n/auspex/slO/chip/euterpe/proteus/custom/stats . eel 

Reading Legal Cell List file 
/n/auspex/slO/chip/euterpe/proteus/leafgen/toptList 

Reading Legal Cell List file 
/n/auspex/slO/chip/euterpe/proteus/exlax/toptList 

Reading Legal Cell List file 
/n/auspex/ slO/chip/euterpe/proteus /custom/ toptList 

Performing Edif Transformations... 

Reading DC Loads file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/dcload/dcload . lib 

Reading DC Loads file 
/n/auspex/slO/chip/euterpe/proteus/exlax/dcload/dcload. lib 

Reading DC Loads file 
/n/auspex/ slO/chip/euterpe/proteus/custom/dcload/dcload. lib 

Reading pin cap values from 
/n/auspex/ slO/chip/euterpe/proteus/leaf gen/ caps/cap , lib 

Reading pin cap values from 
/n/auspex/slO/chip/euterpe/proteus/exlax/caps/ cap . lib 

Reading pin cap values from 
/n/auspex/slO/chip/euterpe/proteus/custom/caps/ cap. lib 

Status information in gards/ctiod-passl . stat Warning! Cell cgclockbias not on legal 
cell list. 

Any gate in it's path is not AC power optimized 
No swing calculations will be performed 
Pruning flattened network of unused instances. . . 2 pruned in 2 
passes . 

Checking/Setting swing values... 

Reading Cap/Delay table file 
/n/auspex/slO/chip/euterpe/proteus/leaf gen/ time/tim . lib 

Reading Cap/Delay table file 
/n/auspex/slO/chip/euterpe/proteus/custom/time/tim . lib 

Warning! Cell cache at line 4 is not in legal cell list Warning! Cell cahalf at line 10 
is not in legal cell list Warning! Cell cr at line 13 is not in legal cell list Warning! 
Cell ctag at line 20 is not in legal cell list Warning! Cell gtlb at line 23 is not in 
legal cell list Warning! Cell sccgbfrO at line 52 is not in legal cell list Warning! 
Cell sccgdr at line 94 is not in legal cell list 

Reading Cap/Delay table file 
/n/auspex/slO/chip/euterpe/proteus/exlax/time/tim. lib 

Connecting floating differential inputs to net vref_0ph. . . 

Connected 0 inputs to net vref_0ph. . . 
DC Load checks only for cell(s): 

eawwlvref 56s7x4a eawwlvref 20sl0xla eawwlvref 16s2x4a xbc01df32s 

xbc01df24s xbc01dfl6s xbc01dfl2s xbc01df8s xbc01df6s xbc01df4s 

xbc01df2s xbcOl xbcmos2ecldf 16s xbcmos2ecldf 12s xbcmos2ecldf 8s 

xbcmos2ecldf 4s xbcmos2ecldf 2s xbcmos2ecl 
Force swing levels for inst(s): 

ctwe/UCTweB7/uO; {df ) ctwe/UCTweB6/u0 ,- (df ) ctwe/UCTweB5/u0 ; (df ) 

ctwe/UCTweB4/u0; (df ) ctwe/UCTweB3/u0 ; (df ) ctwe/UCTweB2/u0 ; (df ) 

ctwe/UCTweBl/uO; (df ) ctwe/UCTweBO/uO ; {df ) muxf f 2_16dinhi/u0 ; (df) 

muxf f2_16dinhi/ul; (df) muxf f 2_16dinhi/u2 ; (df) 
muxff2_16dinhi/u3; (df) 

muxff2_16dinhi/u4; (df) muxf f 2_16dinhi/u5 ; (df) 
muxff2_16dinhi/u6; (df ) 

muxff2_16dinhi/u7; (df) muxf f 2_16dinhi/u8 ; (df) 
muxf f2_16dinhi/u9; (df ) 

muxf f2_16dinhi/ul0; (df ) muxf f 2_16dinhi/ull ; (df ) 

muxff2_16dinhi/ul2; (df) muxf f 2_16dinhi/ul3 ; (df) 

muxf f 2_16dinhi/ul4 ; (df) muxf f 2_16dinhi/ul5 ; (df) 

muxff2_3 2dinlo/u0; (df ) muxf f 2_32dinlo/ul ; (df ) 
muxf f2_32dinlo/u2; (df ) 
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muxff2_3 2dinlo/u3 ; (df) muxf f 2_32dinlo/u4 ; <df) 
muxf f2_32dinlo/u5; (df) 

muxf f2_32dinlo/u6; (df ) muxf f 2_32dinlo/u7 ; (df ) 
muxff2_32dinlo/u8; (df) 

muxf f2__32dinlo/u9; (df ) muxf f 2_32dinlo/ul0 ; (df ) 

muxf f2_32dinlo/ull; (df) muxf f 2_32dinlo/ul2 ; (df) 

muxf f 2_32dinlo/ul3 ; (df) muxf f 2_32dinlo/ul4 ; (df) 

muxf f2_32dinlo/ul5; (df ) muxf f 2_32dinlo/ul6 ; (df ) 

muxff2_32dinlo/ul7; (df) muxf f 2_3 2dinlo/ul8 ; (df) 

muxff2_32dinlo/ul9; (df) muxf f 2_32dinlo/u2 0 ; (df) 

muxff2_32dinlo/u21; (df) muxf f 2_32dinlo/u22 ; (df) 

muxff2_32dinlo/u2 3 ; (df) muxf f 2_32dinlo/u24 ; (df) 

muxff2_32dinlo/u25; (df) muxf f 2_32dinlo/u2 6 ; (df) 

muxff2_32dinlo/u2 7; (df) muxf f 2_32dinlo/u2 8 ; (df) 

muxff2_3 2dinlo/u2 9; (df) muxf f 2_32dinlo/u3 0 ; (df) 

muxff2_32dinlo/u31; (df) muxf f 2_16douthi/u0 ; (dh) 

muxff2_16douthi/ul; (dh) muxf f 2_16douthi/u2 ; (dh) 

muxf f 2_16douthi/u3 ; (dh) muxf f 2_16douthi/u4 ; (dh) 

muxff2_16douthi/u5; (dh) muxf f 2_16douthi/u6 ; (dh) 

muxff2_16douthi/u7; (dh) muxf f 2_16douthi/u8 ; (dh) 

muxf f 2_16douthi/u9; (dh) muxf f 2_16douthi/ulO ; (dh) 

muxf f 2_16douthi/ull; (dh) muxf f 2_l6douthi/ul2 (dh) 

muxff2_16douthi/ul3; (dh) muxf f 2_16douthi/ul4 (dh) 

muxff2_16douthi/ul5; (dh) muxf f 2_32doutlo/u0 ; (dh) 

muxff2_3 2doutlo/ul; (dh) muxf f 2_32doutlo/u2 ; (dh) 

muxf f 2_3 2doutlo/u3 ; (dh) muxf f 2_32doutlo/u4 ; (dh) 

muxf f 2_3 2doutlo/u5 ; (dh) muxf f 2_32doutlo/u6 ; (dh) 

muxf f 2_3 2doutlo/u7 ; (dh) muxf f 2_32doutlo/u8 ; (dh) 

muxff2_32doutlo/u9; (dh) muxf f 2_32doutlo/ul0 ; (dh) 

muxff2_32doutlo/ull; (dh) muxf f 2_32doutlo/ul2 ; (dh) 

muxff2_3 2doutlo/ul3 ,- (dh) muxf f 2_32doutlo/ul4 ; (dh) 

muxff2_32doutlo/ul5; (dh) muxf f 2_32doutlo/ul6 ; (dh) 

muxff2_3 2doutlo/ul7; (dh) muxf f 2_32doutlo/ul8 ; (dh) 

muxf f 2_3 2doutlo/ul9; (dh) muxf f 2_3 2doutlo/u2 0 ; (dh) 

muxff2_3 2doutlo/u21; (dh) muxf f 2_32doutlo/u22 ; (dh) 

muxff2_32doutlo/u23; (dh) muxf f 2_32doutlo/u24 ; (dh) 

muxff2_32doutlo/u25; (dh) muxf f 2_32doutlo/u26 ; (dh) 

muxff2_3 2doutlo/u2 7; (dh) muxf f 2_3 2doutlo/u2 8 ; (dh) 

muxf f2_32doutlo/u2 9; (dh) muxf f 2_3 2doutlo/u3 0 ; (dh) 

muxf f2_3 2doutlo/u31; (dh) 
Warning! No CKFI_AD1PH pin capacitance data for cgclockbias Warning! No CKFI_BD1PH pin 
capacitance data for cgclockbias Warning! No CKRI_AD1PH pin capacitance data for 
cgclockbias Warning! No CKRI_BD1PH pin capacitance data for cgclockbias Warning! No 
CLR_ABM<8> pin capacitance data for cgclockbias Warning! No CLR_ABM<7> pin capacitance 
data for cgclockbias Warning! No CLR_ABM<6> pin capacitance data for cgclockbias Warning! 
No CLR_ABM<5> pin capacitance data for cgclockbias Warning! No CLR_ABM<4> pin capacitance 
data for cgclockbias Warning! No CLR_ABM<3> pin capacitance data for cgclockbias Warning! 
No CLR_ABM<2> pin capacitance data for cgclockbias Warning! No CLR_ABM<1> pin capacitance 
data for cgclockbias Warning! No CLR_ABM<0> pin capacitance data for cgclockbias Warning! 
No PHI_ANM<8> pin capacitance data for cgclockbias Warning! No PHI_ANM<7> pin capacitance 
data for cgclockbias Warning! No PHI_ANM<6> pin capacitance data for cgclockbias Warning! 
No PHI_ANM<5> pin capacitance data for cgclockbias Warning! No PHI_ANM<4> pin capacitance 
data for cgclockbias Warning! No PHI_ANM<3> pin capacitance data for cgclockbias Warning! 
No PHI_ANM<2> pin capacitance data for cgclockbias Warning] No PHI_ANM<1> pin capacitance 
data for cgclockbias Warning! No PHI_ANM<0> pin capacitance data for cgclockbias Warning! 
No PHI_BNM<8> pin capacitance data for cgclockbias Warning! No PHI_BNM<7> pin capacitance 
data for cgclockbias Warning! No PHI_BNM<6> pin capacitance data for cgclockbias Warning! 
No PHI_BNM<5> pin capacitance data for cgclockbias Warning! No PHI_BNM<4> pin capacitance 
data for cgclockbias Warning! No PHI_BNM<3> pin capacitance data for cgclockbias Warning! 
No PHI_BNM<2> pin capacitance data for cgclockbias Warning! No PHI_BNM<1> pin capacitance 
data for cgclockbias Warning! No PHI_BNM<0> pin capacitance data for cgclockbias Warning! 
No RD_BM<8> pin capacitance data for cgclockbias Warning! No RD_BM<7> pin capacitance 
data for cgclockbias Warning! No RD_BM<6> pin capacitance data for cgclockbias Warning! 
No RD_BM<5> pin capacitance data for cgclockbias Warning! No RD_BM<4> pin capacitance 
data for cgclockbias Warning! No RD_BM<3> pin capacitance data for cgclockbias Warning! 
No RD_BM<2> pin capacitance data for cgclockbias Warning! No RD_BM<1> pin capacitance 
data for cgclockbias Warning! No RD_BM<0> pin capacitance data for cgclockbias Warning! 
No SI_AM<8> pin capacitance data for cgclockbias Warning! No SI_AM<7> pin capacitance 
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data for cgclockbias Warning! No SI_AM<6> pin capacitance data for cgclockbias Warning! 
No SI_AM<5> pin capacitance data for cgclockbias Warning! No SI_AM<4> pin capacitance 
data for cgclockbias Warning! No SI_AM<3> pin capacitance data for cgclockbias Warning! 
No SI_AM<2> pin capacitance data for cgclockbias Warning! No SI_AM<1> pin capacitance 
data for cgclockbias Warning! No SI_AM<0> pin capacitance data for cgclockbias Warning! 
No VFFMAX pin capacitance data for cgclockbias Warning! No VFFMIN pin capacitance data 
for cgclockbias Warning! No VFFNOM pin capacitance data for cgclockbias Warning! No 
VFFREFMAX pin capacitance data for cgclockbias Warning! No VFFREFMIN pin capacitance data 
for cgclockbias Warning! No VFFREFNOM pin capacitance data for cgclockbias Warning! No 
VFFREFVAR pin capacitance data for cgclockbias Warning! No VFFVAR pin capacitance data 
for cgclockbias Warning! No VRRG<2> pin capacitance data for cgclockbias Warning! No 
VRRG<1> pin capacitance data for cgclockbias Warning! No VRRG<0> pin capacitance data for 
cgclockbias Warning! No XFER_BM<8> pin capacitance data for cgclockbias Warning! No 
XFER_BM<7> pin capacitance data for cgclockbias Warning! No XFER_BM<6> pin capacitance 
data for cgclockbias Warning! No XFER_BM<5> pin capacitance data for cgclockbias Warning! 
No XFER_BM<4> pin capacitance data for cgclockbias Warning! No XFER_BM<3> pin capacitance 
data for cgclockbias Warning! No XFER_BM<2> pin capacitance data for cgclockbias Warning! 
No XFER_BM<1> pin capacitance data for cgclockbias Warning! No XFER__BM<0> pin capacitance 
data for cgclockbias 

Ignoring these nets: 

phi_B2P phi_A2P vref_0ph 

Optimizing power... 
Iteration: 1 
Path power optimizer 
DC Load Calculations 

Unpowered Instance check: 1 found. 

Iteration: 2 

Path power optimizer 

DC Load Calculations 

Unpowered Instance check: 1 found. 

Squeezing out extra time in paths. 
Iteration: 3 
Path power optimizer 
DC Load Calculations 

Unpowered Instance check: 1 found. 

Savings by squeezing out extra time = (1990 - 1990) = 0.00% Change from original input 
power = (1990 - 256) = 87.14% 

Warning! 1 unpowered or untouched instances. 

NOTE: 4 64 unpowered nets. 

NOTE: 66 nets with delays less than 50.00ps 
NOTE: Power levels changed for 93 instances. 


Atoms: count atom bjt isrc pld clock 

BJT Totals: 150 2345 3858 3905 3586 2405 

Generating instance drive strength file gards/ctiod-passl . strength 
Disgorging sdl file gards/ctiod-passl . sdl 

Writing sdl structure: gards_4 7_ctiod_4 6_edif 

Congratulations! No timing or DC Load violations! 

Memory usage: 23.484MB 
Exit code: 0 (Success) 
CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/ slO/chip/euterpe/ tools /bin/pdlcat -p 

/n/auspex/slO/chip/euterpe/clockbias : /n/auspex/ slO/chip/euterpe/gards/subb 
locks : /n/auspex/slO/chip/euterpe/gards/dcell : /n/auspex/slO/chip/euterpe/pr 
oteus/gards/leaf : /n/auspex/sl0 /chip/ euterpe/proteus/gards/sof a : / n/ auspex/s 
10/chip/euterpe/proteus/gards/dcell "grep -v ' A # ' < gards/ctiod-passl . strength | awk 
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' {print $4; } ' 1 \ 

sort j uniq | awk 1 {printf ("%s.pdl " , $1)}'" > gards/ctiod-passl . macros . temp rav 
gards/ctiod-passl. macros . temp gards/ctiod-passlmacros .pdl 
**** SLNET ctiod-passl 
Thu Oct 27 22:29:21 PDT 1994 

sed -e ' s!DESIGN_NAME! ctiod-passl J ' -e " s ! EDIF_FILE ! Ctiod-passl . sdl ! " \ 

-e ' s JCHIPROOT!/n/auspex/slO/chip/euterpe! ' -e ' s ! TECH_GPLACE ! ctiod- 
passl . gplace . mobi234 ! 1 \ 

-e ' s!TECH_REDIT! ctiod-passl. redit.mobi2 34 ! 1 \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/ctiod-passl . vrf echo "cd 

~abspathVgards; \ 

echo translate_all j HOME=/n/auspex/slO /chip/euterpe/tools 
LM_LICENSE_FILE= /n/auspex/slO /chip/euterpe/tools/ si/ license/license .dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=50 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/net/dir/slnet ctiod-passl" | /usr/local/bin/rexec 
ghidra sh 

** SLNET 1.037 ** SL_NET VI. 000 -- Netlist Manipulator Copyright (c) 1993,1994 SILVAR- 
LISCO. All rights reserved. 

Design: ctiod-passl Started at: 94/10/27 22:29:23 


Loading file "ctiod-passl . sdl" . 
[XBFFDF6S] 
[XBFFBDH1 2 S ] 
[XBFFDH8S] 
[XBFFDH4S] 
[XBFFDH2S] 
[XBFFDF4S] 
[XBORFF2DF4S] 
[XBORFF2DH16S] 
[XBORFF2DH8S] 
[XBORFF2DH4S] 
[XBMUXFF3DH2 4 S J 
[XBMUXFF2DF24S] 
[XBMUXFF2DH4S] 
[XBC01DF2S] 
[XBMUX2DH2S] 
[XBOR2DF16S] 
[XBOR2DF4S] 
[XBOR3DF4S] 
[XBORFF3DF8S] 
[XBORFF4DF24S] 
[CGCLOCKBIAS] 
[CTIOD] 

** Warning: No nets connected to component CGCLOCKBIAS. 
Translating. . . 
[XBFFDF6S] 
[XBFFBDH12S] 
[XBFFDH8S] 
[XBFFDH4S] 
[XBFFDH2S] 
[XBFFDF4S] 
[XBORFF2DF4S] 
[XBORFF2DH16S] 
[XBORFF2DH8S] 
[XBORFF2DH4S] 
[XBMUXFF3DH24S] 
[XBMUXFF2DF24S] 
[XBMUXFF2DH4S] 
[XBC01DF2S] 
[XBMUX2DH2S] 
[XBOR2DF16S] 
[XB0R2DF4S] 
[XBOR3DF4S] 
[XBORFF3DF8S] 
[XBORFF4DF2 4 S ] 
[CGCLOCKBIAS] 
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[CTTODJ 


Netlist Info : 


Number of logic types 
Number of nets 
Number of components 
Number of component pins 
Number of pins/comp 
Number of nets/comp 

Size estimation : 

| TYPE 


21 
580 
150 
1696 

11.306667 
3 .866667 


| # inst | size/inst | total 


| XBMUX2DH2S 

1 1 

1 1 

1 1 

| XBFFDH4S 

1 2 

| 1 

| 2 

| XBFFDH2S 

1 1 

| 1 

| 1 

| XBORFF2DH16S 

] 1 

j 1 

| 1 

| XBMUXFF2DH4S 

| 48 

1 1 

| 48 

| XBOR2DF4S 

1 1 

1 1 

1 1 

| CGCLOCKBIAS 

1 1 

1 1 

1 x 

| XBMUXFF2DF24S 

| 48 

1 1 

| 48 

| XBORFF3DF8S 

1 8 

| 1 

1 8 

| XBORFF2DH8S 

1 1 

I 1 

1 1 

| XBFFBDH12S 

| 1 

| 1 

1 1 

| XBOR3DF4S 

| 1 

1 1 

1 X 

} XBFFDF4S 

1 7 

1 1 

1 7 

| XBFFDF6S 

1 2 

1 1 

1 2 

J XBORFF2DH4S 

I 4 

1 1 

1 4 

| XBOR2DF16S 

1 3 

1 1 

1 3 

| XBFFDHSS 

| 1 

1 1 

1 1 

j XBORFF2DF4S 

1 1 

1 1 

1 1 

| XB0RFF4 DF2 4 S 

1 1 

1 1 

| 1 

| XBC01DF2S 

1 1 

I 1 

1 X 

| XBMUXFF3DH2 4 S 

1 16 

1 1 

1 16 


TOTAL 


| 150 


I 1 


| 150 
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Warning : No "SL_SIZE" attributes found on the cells! 
Default size (1) was used for all cells. 

To change this default add an attribute " SL_SIZE" to the cells, 

slnet > 22:29:27 Terminating Normally on 94/10/2 7 

Elapsed CPU time 00:00:04 

Elapsed wall time 00:00:04 
End of Program 


Normal Termination . . . 

Thu Oct 27 22:29:27 PDT 1994 

**** PCOMP ctiod-passl 

Thu Oct 27 22:29:28 PDT 1994 

sed -e ' s ! DESIGN_NAME ! ctiod-passl ! ' -e " s ! EDIF_FILE ! ctiod-passl . sdl ! " \ 

-e ' s 1CHIPR00T! /n/auspex/slO/chip/euterpe! ' -e 1 s ! TECH_GPLACE ! ctiod- 
passl . gplace .mobi2 3 4 ! ' \ 

-e ' s 1TECHREDIT I ctiod-passl. redit .mobi234 ! ' \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/ctiod-passl . vrf rm -f 
gards/ctiod-passl .dff (echo "cd "abspath Vgards; \ 

HOME=/n/auspex/sl0/chip/euterpe/tools 
LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/ si/ license/license .dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke pcomp ctiod-passl -listing ctiod- 
passl .pcomp . lis" | /usr/local/bin/rexec ghidra sh && sleep 10 && \ 

HOME=/n/auspex/slO /chip /euterpe/ tools 
LM_LlCENSE_FlLE=/n/auspex/slO/chip/euterpe/ tools/ si /license/license . dat 
DISPLAY=clio : 0 . 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/slO/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -ds gards/ctiod-passl ) | | (mv gards/ctiod- 
passl . pcomp . lis gards/ctiod-passl .pcomp . lis . ERROR; false) 

Requires a minimum license of gardsfel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS PCOMP 7.121 -- Physical Compiler 

Copyright (c) 1994 SILVAR-LISCO . All rights reserved. 
Design: ctiod-passl Started at : 94/10/27 22:29:34 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: CTIOD 
Processing Expansion level: SLNET 

. . . Start of netlist processing. 

. . . Circuit name : CTIOD 

. . . Processing CDL. 

. . . CHIPNAME : SOFA; 


. . . Processing header of user pdl. 

. . . PHYSICALLIB : PBUILD ; 

. . . Processing header of system PDL. 

. . . PHYSICALLIB: PBUILD; 

... Processing rest of user PDL. 

... Processing rest of system PDL. 

. . . Processing TDL. 

. . . TECHNOLOGYLIB : SOFA; 

. . . Computed Grid Size = 1000 

. . . Final Processing. 

. . . Successful physical compilation (with warnings) . 

>>> Loading logical netlist. 

. . . Successful completion. GARDS design file created. 

Terminated at : 94/10/27 22:29:45 

Elapsed CPU time : 0 Hrs 0 Mins 6 Sees 
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Elapsed wall clock time : 0 Hrs 0 Mins 11 Sees 
Thu Oct 27 22:29:56 PDT 1994 
HOME=/n/auspex/ slO/chip/euterpe/tools 

LMJLlCENSE_FILE=/n/auspex/slO/chip/euterpe/tools/sl/license/license.dat 
DISPLAY=clio: 0. 0 SL_TOTAL_DXJRATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif gards/ctiod-passl .pim -xrf gards/ctiod- 
passl.xrf -dff gards/ctiod-passl . dff -noHole \ 

-obstructionPdl /n/auspex/slO/chip/ euterpe/gards/ sofa/sofa . pdl \ 
-obstructionCdl /n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl \ 
-libraryPdl gards/ctiod-passlmacros . pdl -eel -tech mobi -sdl \ 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Preparing input files... 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa. pdl . . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Reading gards/ctiod-passl . dff . .. 
/n/ auspex/slO/ chip/ euterpe/ tools /bin/pim2pi f : Fetching bounding box from 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa . cdl . . . 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Checking 

/n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl for fixed obstructions. . . 
/n/auspex/slO/chip/euterpe/ tools/bin/pim2pif : Checking 

/n/auspex/slO/chip/euterpe/gards/sof a/sofa. cdl for Eel obstructions... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif : Processing the gards/ctiod-passl .pirn file... 
/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 67 rows (67 non-empty) ...spanning 4 
columns (4 maximum cells/row) ...for a total of 147 cells were written to "gards/ctiod- 
passl .pirn. pif . 0 ' . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: (1726, 875) to (1872, 
1076) [73 by 67 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 2341 ECL atoms placed in 

4891 [-0 obstructions] atom area [47.86% dense] #pim2pif.ex Version 0.2.27 Sat Oct 15 

16:22:33 PDT 1994 HOME=/n/auspex/slO/chip/euterpe/tools 

LM_LICENSE_FILE=/n/auspex/ si 0 /chip/euterpe/tools/sl /license/license . dat 
DISPLAY=clio:0 .0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack gards/ctiod-passl . pim . pif -obstructionPdl 
/n/auspex/slO/chip/euterpe/gards/sof a/ sofa .pdl \ 

-obstructionCdl 
/n/auspex/slO/chip/euterpe/gards/sofa/sof a . cdl \ 

-libraryPdl gards/ctiod-passlmacros .pdl -eel -tech mobi \ 

-trueSqueeze -1 -distance -1 -packBothEdges 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Preparing input files... 
/n/auspex/slO/chip/euterpe/tools/bin/pifpack: Fetching bounding box from 
/n/auspex/ si 0/chip/euterpe/gards/ sofa/ sofa . cdl . . . 
/n/ auspex/slO /chip/euterpe/ tools/bin/pifpack : Reading 
/n/auspex/slO /chip/euterpe/gards/sof a/sofa. cdl . . . 
/n/auspex/ si O/chip/euterpe/tools/bin/pif pack: Reading 
/n/auspex/slO/chip/euterpe/gards/sof a/sofa .pdl . . . 

/n/auspex/slO/chip/euterpe/tools/bin/pifpack : Packing right edge. . . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex : Final width 73 ECL atoms, squeezed out 0 
ECL atoms . . . which may include up to 0 ECL atoms of obstructions 

/n/auspex/s!0/chip/euterpe/tools/bin/pim2pif .ex: 67 rows (67 non-empty) ...spanning 3 
columns (4 maximum cells/row) ...for a total of 147 cells were written to "gards/ctiod- 
passl . pim . pif . packed 1 . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (1726, 875) to (1872, 
1076) [73 by 67 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 2341 ECL atoms placed in 

4891 [-0 obstructions] atom area [47.86% dense] #pim2pif.ex Version 0.2.27 Sat Oct 15 

16:22:33 PDT 1994 

/n/auspex/slO/chip/euterpe/ tools/bin/pifpack: Packing left edge... 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: Final width 73 ECL atoms, squeezed out 0 
ECL atoms . . .which may include up to 0 ECL atoms of obstructions 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 67 rows (67 non-empty) ...spanning 3 
columns (4 maximum cells/row) ...for a total of 147 cells were written to "gards/ctiod- 
passl .pim. pif .packed" . 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: (1726, 875) to (1872, 
1076) [73 by 67 ECL atoms] 

/n/auspex/sl0/chip/euterpe/tools/bin/pim2pif .ex: 2341 ECL atoms placed in 

4 8 91 [-0 obstructions] atom area [47.86% dense] #pim2pif.ex Version 0.2.27 Sat Oct 15 

16:22:33 PDT 1994 HOME=/n/auspex/sl0/chip/euterpe/tools 

LM_LICENSE__FILE= /n/auspex/ si 0 /chip/euterpe/tools/sl /license/ license . dat 
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DISPLAY=clio: 0 . 0 SLJTOTAL_DURATION=500 CHIPROOT=/n/auSpex/ slO / chip/euterpe 
/n/auspex/ slO /chip/euterpe/ tools/bin/pif2pim 

gards/ctiod-passl .pim. pif .packed -xrf gards/ctiod-passl . xrf -dff gards/ctiod-passl .dff \ 
- obstruct ionPdl /n/auspex/ slO /chip/ euterpe/gards/ sofa/sofa.pdl \ 
-obstruct ionCdl /n/auspex/slO/chip/euterpe/gards/sof a/sof a . cdl \ 
-libraryPdl gards/ctiod-passlraacros .pdl -eel -tech mobi -sdl \ 
-collapseRows -noSpacers -noAlign -noOffset 

/n/auspex/slO/chip/euterpe/tools/bin/pif 2pim : Preparing input files... 

/n/auspex/slO/chip/euterpe/tools/bin/pif 2pim: Reading gards/ctiod-passl . dff . . . 

/n/auspex/slO/chip/euterpe/tools/bin/pif 2pim: Reading 

/n/auspex/slO/chip/euterpe/gards/sof a/sof a. pdl . . . 

/n/auspex/ slO /chip/euterpe/ tools/bin/pif 2pim : Fetching bounding box from 
/n/auspex/slO/chip/euterpe/gards/sofa/sofa. cdl . . . 
/n/auspex/sl0/chip/euterpe/tools/bin/pif2pim: Reading 
/n/auspex/slO/chip/euterpe/gards/sofa/sofa. cdl . , , 

//n/auspex/sl0/chip/euterpe/tools/bin/pim2pif . ex: 199 rows 5 columns written to 
"gards/ctiod-passl .pirn. pif .packed. pira 1 

#pim2pif.ex Version 0.2.27 Sat Oct 15 16:22:33 PDT 1994 mv gards/ctiod- 
passl .pirn . pif . packed gards/ctiod-passl . pif 
**** GPLACE ctiod-passl 
Thu Oct 27 22:30:38 PDT 1994 

sed -e ' s IDES IGNNAME ! ctiod-passl ! ' -e " s ! EDIF_FILE ! ctiod-passl . sdl I " \ 

-e ' s 1CHIPROOT! /n/auspex/slO/chip/euterpe ! ' -e • s ! TECH_GPLACE ! ctiod- 
passl .gplace.mobi234 I 1 \ 

-e ' s !TECH_REDIT! ctiod-passl. redit .mobi234 ! 1 \ 

< /n/auspex/slO/chip/euterpe/proteus/misc/gards . vrf > gards/ctiod-passl . vrf rm -f 
gards/ctiod-passl . gplace . nic cd gards; if HOME=/n/auspex/sl0/chip/euterpe/tools 
LM_LI CENS E_F I LE=/ n/auspex/ slO/chip/euterpe/ tools/sl/license/license . dat 
DISPLAY=clio: 0 . 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -p -s ctiod-passl; then \ 

/usr/5bin/echo ' deletegroup use; ok* > ctiod-passl . gplace . nic ; fi 
/usr/5bin/echo ' readpif ctiod-passl .pif ; ok 1 >> 
gards/ctiod-passl .gplace .nic 

/usr/5bin/echo 'makeauto use; ok' >> 
gards/ctiod-passl . gplace . nic 

/usr/5bin/echo 1 iparam sweeps 0;' » 
gards/ctiod-passl . gplace . nic 

/usr/5bin/echo 'iparam algorithm hper_net length ; ' >> 
gards/ctiod-passl . gplace . nic 

/usr/5bin/echo 'improve use; ok' >> 
gards/ctiod-passl .gplace .nic 

/usr/5bin/echo ' writenof ctiod-passl . nof ; use; ok 1 >> 
gards/ctiod-passl . gplace . nic 

/usr/5bin/echo 1 exitsave\nexitnosave 1 >> 
gards/ctiod-passl . gplace .nic 
(echo "cd ""abspath" /gards; \ 

HOME=/n/auspex/sl0/chip/euterpe/tools 
LM_LlCENSE_FlLE=/n/auspex/slO/chip/euterpe/tools/ sl/license/license . dat 
DISPLAY=cliO: 0 . 0 SLJTOTAL_DURATION=500 CHIPROOT=/n/auspex/sl0/ chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/sl/bin/invoke gplace ctiod-passl -listing ctiod- 
passl . gplace . lis -cmdin ctiod-passl . gplace . nic -colorin 
ctiod-passl. gplace. mobi234 -inbat 1" | \ 

/usr/local/bin/rexec ghidra sh && 
HOME=/n/auspex/sl0 /chip/euterpe/ tools 

LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tools/ sl/license/license . dat 
DISPLAY=cliO: 0 . 0 SL_TOTAL_DURATION=50 0 CHIPROOT=/n/auspex/sl0/chip/euterpe 
/n/auspex/slO/chip/euterpe/tools/bin/gastatus -sp gards/ctiod-passl) | J (mv gards/ctiod- 
passl. nof gards/ctiod-passl .nof .ERROR; rm -f ctiod-passl . nof ; false) 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gards conf ig__3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS GPLACE 7.126 -- General Placer 

Copyright (c) 1994 SILVAR-LISCO . All rights reserved. 
Design: ctiod-passl Started at: 94/10/27 22:30:43 
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G PLACE Version 7.1.2 6 of September 9, 1994 


No component hierarchy found; select by hierarchy disabled. 

Loading components. . . 

Loading nets . . . 

Loading logical types... 

Processing physical types. . . 

Loading cell_types. . . 

Creating net-comp xref table. . . 


Terminated at : 94/10/27 22:33:02 

Elapsed CPU time : 0 Hrs 1 Mins 55 Sees 

Elapsed wall clock time : 0 Hrs 2 Mins 19 Sees 
gmake [2] : *** [gards/ctiod-passl . nof ] Error 1 
gmake[2] : Leaving directory 

/N/auspex/ root/slO/chip/ euterpe/verilog/bsrc/ ctiod ' 
gmake [1] : *** [ctiod-base . netcap] Error 1 
gmake [1] : Leaving directory 

VN/auspex/root/slO/chip/euterpe/verilog/bsrc/ctiod' 
gmake: *** [ctiodgards] Error 1 
HOME=/n/auspex/sl0/chip/euterpe/tools 

LM_LICENSE_FILE=/n/auspex/slO/chip/euterpe/tobls/sl/license/license .dat 
DISPLAY= SL_TOTALJDURATION=500 CHIPROOT=/n/auspex/slO/chip/euterpe 
. . /export_obs ctiod-iter ctiod 

/n/auspex/slO/chip/euterpe/compass/vlsi. boo-all 
###Creating ctiod-iter . gil 

Warning, VRF file does not exist, creating file "ctiod-iter .vrf" . 

** Error ** The file "ctiod- iter , dff " does not exist. File variable = "Design_f ile" . 
gmake: *** [gards/ctiod . obs] Error 255 

[finished at Thu Oct 27 22:33:10 PDT 1994 exit status 1] 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Friday, October 28, 1994 12:47 AM 
To: 'dickson@ambiorix'; 'tb^ambiorix' 
Cc: lisa^ambiorix' 
Subject: toplevel release 

Rich checked in a bunch of datapath directories. I did a 
getbom in bsrc, but then I noticed that the latest datapath 
changes are not incorporated yet at the top-level. The toplevel 
euterpe. V dooes not compile with the latest version of the datapth. 

I cannot make progress until I have a toplevel euterpe. V that 
compiles with the new datapath blocks. 


Geert 
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From: 
Sent: 
To: 

Subject: 


Lisa Robinson [lisar@nosferatu] 
Friday, October 28, 1994 1:09 AM 
'Geert Rosseel' 
toplevel release 


Geert Rosseel wrote (on Thu Oct 27) : 


Rich checked in a bunch of datapath directories. I did a 
getbom in bsrc ( but then I noticed that the latest datapath 
changes are not incorporated yet at the top-level. The toplevel 
euterpe.V dooes not compile with the latest version of the datapth. 

I cannot make progress until I have a toplevel euterpe.V that 
compiles with the new datapath blocks. 


Did you pick up Rich's euterpe.V? 


revision 6.2 72 

date: 1994/10/2 7 18:56:43 LT; author: dickson; state: Exp; lines: +11 
-8 

interface changes in data path associated with removal of 4 bit ops. 

also fixed tau problem in mc. eta top level change for store data buss, if stores dont 
work tau fix was bad. 


Geert 


Lisa R. 


Exhibit C7 


Page 624 of 703 


From: 
Sent: 
To: 


sysadm@gaea on behalf of Bob Morgan [bobm@microunity.com] 

Friday, October 28, 1994 12:08 PM 

'euterpe@gaea' 


Hi, 

I just released version 1.4 of the Euterpe MicroArchitecture document. As usual, you can 
print out a copy by using the Makefile in /euterpe/doc and typing "gmake book" . Or, if 
you would prefer a bound copy, let me know and I'll print one out for you. Any 
suggestions or corrections grudgingly accepted. ;-) Thanks, Bob 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microun ity.com] 

Friday, October 28, 1994 1:35 PM 

'lisa' 

tgdb malloc failure 


Try running the following from -gregg/ stb/lib/util/tests : 

tgdb testgetl2 8 
r < b 

You'll find that tgdb aborts with the following backtrace: 

gdb internal error: Memory corruption 

Program received signal SIGQUIT, Quit. 
0xfae7148 in kill 0 at gethostent . c : 87 
gethostent . c : 87 : No such file or directory, 
(ogdb) bt 

#0 0xfae7148 in kill () at gethostent . c : 87 

#1 0x57c4e8 in f atal_dump_core ( builtin_va_alist=268764056) at 

utils . c :356 

#2 0x57cd2c in malloc_botch () at utils. c: 615 

#3 0x5ca814 in checkhdr (mdp=0x3d44 , hdr=0x3) at mmcheck.c:65 
#4 0x5ca8b8 in mfree_check (md=0x0, ptr=0x3) at mmcheck.c:78 
#5 0x5c9928 in mfree (md=0x0, ptr=0xl0837008 ) at mfree.c:227 
#6 0x5c99c4 in free (ptr=0x3) at mfree.c:246 

#7 0x4d4bf4 in sim_f ile_read (fd=-l, lva=16780338 , len=-l) at 
memory. c:2028 

#8 0x4e83bO in stb_file_io (scno=15684) at stbgateway . c : 77 

#9 0x4e995c in stb_bgateway (addr=0x3d4400000003 , pnew_j?c=0x7f f f aa60 ) 

at stbgateway . c : 304 
#10 0x48b7e0 in execute (time_it=l) at execute . c : 274 

#11 0x47c2e8 in sim_resume (stepping=15684 , siggnal=3) at simgdb.C:358 
#12 0x47b078 in gdbsim_resume (pid=15684, step=0, s iggna 1 = TARGET_S I GNAL_0 ) 

at remote-sim. c : 307 
#13 0x463af4 in resume (step=0, sig=TARGET_SIGNAL_0) at infrun.c:229 
#14 0x4 63 f 04 in proceed (addr=42 94 967295 , s i ggnal = TARGET_S IGNAL_DE FAULT , 

step=0) at infrun.c:354 
#15 0x4 7acb4 in gdbsim_create_inf erior ( 

exec_f ile=0xl00c8b88 

"/N/auspex/root/s42/gregg/stb/lib/util/tests/test_getl28" , args=0xl00b4f 18 "< b" , env= 

0xl00bef08) at remote-sim. c : 226 

#16 0x517a80 in find_default_create_inf erior ( 

exec_f ile=0xl0 0c8b88 
H /N/auspex/root/s42/gregg/stb/lib/util/tests/test_getl28" , 
allargs=0xl00b4fl8 

"< b", env=0xl0 0bef08) at target. c: 786 

#17 0x4 601e8 in run_command (args=0x0, from_tty=l) at infcmd.c:260 

#18 0x5 75f6 8 in execute_command (p=0xl0 0b50 09 " " , from_tty=l) at top. c: 57 0 

#19 0x5762c0 in command_loop {) at top. c: 629 #20 0x581560 in main (argc=2, argv= 

0x7fffaf04) at main. c: 511 

(ogdb) f 3 

#3 0x5ca814 in checkhdr (mdp=0x3d44, hdr=0x3) at mmcheck.c:65 
65 (*mdp -> abort func) 0 ; 

(ogdb) f 7 

#7 0x4d4bf4 in sim_f ile_read <fd=-l, lva=16780338 , len=-l) at 

memory . c : 2028 

2028 free (buf ) ; 


(ogdb) li 


2023 
2024 
2025 
2026 
2027 


ret = read (fd 7 buf, len) ; 
if (ret > 0) { 


if (memory_access (lva, buf, len, WRITE) < 0) 


ret = -1; 


} 
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2 02 8 free (buf ) ; 

2 02 9 return ret; 

2030 } 
2031 

2032 /* 

Terp also fails, but differently. 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94 08 9-1015 gregg@microunity.com 
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From: Bob Morgan [bobm@mercury] 
Sent: Friday, October 28, 1 994 1 :37 PM 
To: 'tbr@mercury' 
Subject: RE: 

I'll just leave his copy in his mailbox. 
Bob 

Begin Included Message 

>From mouss@charybdis Fri Oct 28 1 1:35:05 1994 
Date: 28 Oct 1994 11:32:56 -0800 
From: "mouss" <mouss@charybdis> 
Subject: RE: 

To: "Bob Morgan" <bobm@MicroUnity.com> 
Content-Length: 514 

I'd like a copy in my mailbox, please! 


From: Bob Morgan on Fri, Oct 28, 1994 10:15 AM 
To: euterpe@gaea 

Hi, 

I just released version 1 .4 of the Euterpe 
MicroArchitecture document. As usual, you can 
print out a copy by using the Makefile in 
/euterpe/doc and typing "gmake book". Or, if 
you would prefer a bound copy, let me know 
and I'll print one out for you. Any suggestions 
or corrections grudgingly accepted. ;-) 
Thanks, 
Bob 


End Included Message 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, October 28, 1994 4:13 PM 
'software-checkins-dist' 
gnu-tools/sim/terp ir.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

ir . c 
Log Message: 

When exit ting because END_OCTLET is touched, stuff the exit status into r2 so it will be 
returned as the real exit status. 
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From: lisa 

Sent: Friday, October 28, 1 994 4:58 PM 

To: 'guarino' 
Subject: better terp 

is now in ~lisa/sgi5. 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 
Friday, October 28, 1994 6:43 PM 
'geert@rhea' 
pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/mc BOM 34.0 initiated by dickson completed @ Fri Oct 28 
16:41:19 pdt 1994 with exit status 0.. chip 

lock read: File exists 
all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, October 28, 1994 6:52 PM 
'software-checkins-dist' 
gnu-tools/si m/terp memory. c 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

In sim_f ile_read{ ) and sim_f ile_write ( ) , if the *signed* length is negative, don't even 


try, and just return error. 
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From: 
Sent: 


tor 

Saturday, October 29, 1994 2:09 AM 


Subject: 


To: 


'bobm' 

forwarded message from William Herndon 


Follow Up Flag: Follow up 
Flag Status: Red 

Can you make a not about this in the document please? (talk to ong 
and dickson for more input). The issue is that when the expansion 
hermes channel is disabled we'll need to turn off the output drivers 
also to prevent EMI from the expansion connector. 


Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["2371" "Fri" "21" "October" "1994" "10:53:40" "-0700" "William Herndon" "bi1l@polyhymnia" nil "58" "Re: Belated 
Netlist meeting notes" " A From:" nil nil "10" nil nil (number " " mark "N William Herndon Oct 21 58/2371 Y'Re: Belated 
Netlist meeting notes\"\n") nil]) 
Return -Path: <bill@polyhymnia> 

Received: from aphrodite.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA17174; Fri, 21 Oct 94 10:53:44 PDT 
Received: from polyhymnia.microunity.com by aphrodite.microunity.com (8.6.4/muse-sw.2) 

id KAA23268; Fri, 21 Oct 1994 10:53:41 -0700 
Received: from localhost by polyhymnia.microunity.com (8.6.4/muse-sw,2) 

id KAA02393; Fri, 21 Oct 1994 10:53:40 -0700 
Message-Id: < 1994 1021 1 753.KAA02393@polyhymnia.microunity.com> 
From: bill@polyhymnia (William Herndon) 
To: tbr@aphrodite, ong@ares 

Cc: wayne@mercury, bill@aphrodite, ong@aphrodite 
Subject: Re: Belated Netlist meeting notes 
Date: Fri, 21 Oct 1994 10:53:40 -0700 


> From ong@ares Fri Oct 21 10:27:59 1 994 

> From: ong@ares (Warren R, Ong) 

> Subject: Re: Belated Netlist meeting notes 

> To: tbr@aphrodite (Tim B. Robinson) 

> Date: Fri, 21 Oct 94 10:27:52 PDT 

> Cc: wayne@mercury, bill@aphrodite, ong@aphrodite 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content-Length: 1852 


> >From Tim B. Robinson ... 

>@ 
>@ 

> @ Wayne Freitas wrote (on Wed Oct 19): 
>@ 

>@ 
>@ > 

> @ > The question was asked if we can completely shut off the second Hermes 

> @ > channel when nothing is plugged to the expansion port to avoid a 
>@ > potential EMI problem, tbr thinks yes, but needs to check. Issue is 


Tim 


> 
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> @ > whether knob controls allow output current to be set to 0. The 

> @ > logical "Channel Disable" is not enough because it causes idle packets 

> @ > to be transmitted continuously. 

>@ > 

> @ > Action: tbr to confirm we can shut this off completely. 

>@ > 
>@ > 

> @ Tim, excuse me if I ask a dumb question, but being that Euterpe actually 

> @ has two Hermes channels, I would think that they would be independent. 

> @ If this is the case wouldn't you have either seperate enables and idle 

> @ pattern registers. Sorry I don't have a copy of the Euterpe Micro-architechure 

> @ document 
>@ 

> @ The share a common idle patem since that is built into the protocol. 

> @ They have separate channel disable bits (Cerberus controlled), but the 

> @ definition of disabled in that sense is the that the output sends out 

> @ idles and the input is ignored. What we need here is an electrical 

> @ disable so we are not toggling the data lines constantly. 
>@ 

> @ Bill, warren, do you know if we can set the output current to 0 for 

> @ sure? 

>@ 
> 

> There are 2 bellybuttons in each iobyte, one bellybutton is 

> controlled by vfCvrr and the other one is controlled by vffc/vrrc. 

> To completely shut off current in iobyte would require setting all 

> pins of vfrT2:0] and vffc[2:0] to vdde (and I guess vrr[2:0] and 

> vrrc[2:0] to vdde - Ov @ OuA). Bill thinks that there is a 

> Cerberus setting to do this. I had thought there might have been 

> an issue with gate punch through, but this is not an issue since 

> the punch through voltage is 3.6V. 
> 

> 

> Warren. 

> 

one of the logic swing codes is 0. set the bellybutton that controls the logic 
swing to 0 and there is no output current 
End of forwarded message 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Saturday, October 29, 1994 12:31 PM 

To: 'geert@aphrodite' 

Subject: snapshot euterpe 


What's the story with the snapshot? The only thing I see built in s41 
is ck. Which versions should I be lookign at? 

Tim 
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To: 


Subject: 


Sent: 


From: 


tbr 

Saturday, October 29, 1994 1:30 PM 
'Geert Rosseel' 
euterpe snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Oct 29): 


Nothing is build in the snapshot yet. The latest build was done 
bu Tom Vo (baseplate containing only ck) to get a DRC/LVS netlist 
Since yesterday. I've started rebuilding the stuff in /u/chip that 
I need to get the datapath. I've got all of that now, and I am 
ready to start routing experiments on the datapath locally. 

OK, so should I go ahead and try building in the snapshot area, 
cleaning up all but the final files as I go? (We seem to have plenty 
of idle machines at present.) 


Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Saturday, October 29, 1994 1:30 PM 

To: 'Geert Rosseel' 

Subject: euterpe snapshot 


Geert Rosseel wrote (on Sat Oct 29) : 


Nothing is build in the snapshot yet. The latest build was done 
bu Tom Vo (baseplate containing only ck) to get a DRC/LVS netlist. 
Since yesterday. I've started rebuilding the stuff in /u/chip that 
I need to get the datapath. I've got all of that now, and I am 
ready to start routing experiments on the datapath locally. 

OK, so should I go ahead and try building in the snapshot area, cleaning up all but the 
final files as I go? (We seem to have plenty of idle machines at present.) 


Tim 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Saturday, October 29, 1994 1:34 PM 
To: 'tbr@aphrodite' 
Subject: Re: euterpe snapshot 

Hi Tim, 

That sounds like a great idea ... it will be a big help. I think that once 
taht is working, I can then link from my local directory to this area 
if I wanr ro do local experiments. I believe the latest BOM (released 
yesterday evening) is a good one for placement. 

Geert 
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From: 


tbr 


Sent: 


Saturday, October 29, 1994 1:38 PM 


Subject: 


To: 


'Geert Rosseel' 

Re: euterpe snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Oct 29): 
Hi Tim, 

That sounds like a great idea ... it will be a big help. I think that once 
taht is working, I can then link from my local directory to this area 
if I wanr ro do local experiments. I believe the latest BOM (released 
yesterday evening) is a good one for placement. 

OK. I'm building the .v's now in my local area from that bom so I'm 
up to date, so I can try local experiments also. I will update the 
snapshot to thet BOM before I build the blocks there, but I will check 
with Tom fist that that won't destry his LVS. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, October 29, 1994 1:38 PM 
'Geert Rosseel' 
Re: euterpe snapshot 


Geert Rosseel wrote (on Sat Oct 29) : 
Hi Tim, 

That sounds like a great idea ... it will be a big help. I think that once 
taht is working, I can then link from my local directory to this area 
if I wanr ro do local experiments. I believe the latest BOM (released 
yesterday evening) is a good one for placement. 

OK. I'm building the .v's now in my local area from that bom so I'm up to date, so I can 
try local experiments also. I will update the snapshot to thet BOM before I build the 
blocks there, but I will check with Tom fist that that won't destry his LVS . 


Tim 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr 

Saturday, October 29, 1994 3:08 PM 
'John Campbell' 

'agc@aphrodite'; 'solo@aphrodite' 
Re: PCI bus clocking. 


Follow Up Flag: Follow up 
Flag Status: Red 

John Campbell wrote (on Tue Oct 25): 
as Tim B. Robinson was saying 


..In the pandora system we will have to figure out how to get both 
..Mnemosynes on the PCI bus to be in the same clock domain. One way 
..to get the 54Mz reference the Pandora Euterpe needs from the Hermes 
..expansion connector out of Hestia. However, we also want Pandora to 
..work stand alone, which suggests is will have to have it's own 
..oscillator. We might have to consider some kind of swicthing 
..according to whether Hestia is there or not. 

..Even with the common reference we will have to deal with arbitrary 
..phase differences. Without it I assume we have to have some kind of 
..synchronizer operating at the order of the PCI clock rate. My reading 
..of the spec says that frequency can be anything less than 33MHz, but I 
..assume we would want to run it close to the max. If so, what's your 
..estimate of synchronizer failure rate? 


I am Assuming we are looking for data at approximately 800ps cycle which is 
all i have quick data on. 

>From some old data, last november, i predict approximately 
1 .3 failures per second with a single flip flop. With two this is 
probably ~1 failure every 2 years. This is at 3 3 MHz on pci and 800ps 
on the sofa, not quite right. 

i am redoing my data for a patent disclosure in the next few weeks so 
i dont mind getting better data sooner if you like, these numbers are 
close. I will guarantee them within 1000%. 

What i need to know is what the frequency of the pci is. what the 
freq of the ~gHz clock is. what time you plan to sample, presumably 
at the ~gHz clock rate, whether you are full swing or half swing 
coming in. rise time of input signal (at the ff> probably buffered so 
we can assume our normal rise time and full swing. 

We should assume 33MHz for PCI and 1 .3GHz for the sofa (though it will 
almost certainly be 1 .08GHz in practice). As for swing etc, we can 
presumably buffer as required to get the best performance. 

for you and alan, clock rate of pci and chip clock speed on the phia 


..Tim 
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phib of the synchronizer. 

let me know when you need the data, i will then get motivated to push 
it up the stack. 

We won't be getting to look at the details of the PCI for a couple of 
weeks yet. 

Tim 
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To: 

Subject: 


Sent: 


From: 


tbr 

Saturday, October 29, 1994 3:14 PM 
'fgp'; 'ken' 

forwarded message from Derek Iverson 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["30670" "Wed" "26" "October" "1994" "08:27:17" "-0700" "Derek Iverson" "doi@demeter " nil "803" "Re: source 
repository" " A From:" nil nil "10"]) 
Return-Path: <doi@demeter> 

Received: from aphrodite.microunity.com by gaea.microunity.com (4.1 /muse 1.3) 

id AA12690; Wed, 26 Oct 94 06:40:43 PDT 
Received: from demeter.microunity.com by aphrodite.microunity.com (8.6.4/muse-sw.2) 

id IAA28179; Wed, 26 Oct 1994 08:27:21 -0700 
Received: from localhost by demeter.microunity.com (8.6.4/muse-sw.2) 

id IAA 17798; Wed, 26 Oct 1994 08:27:17 -0700 
Message-Id: <1 994 1 026 1 527.IA Al 7798@demeter.microunity.com> 
In-Reply-To: <1 994 1 0261 458.HAA2379 1 @clio.microunity .com> 
References: <1 994102605 1 6.WAA26384@aphrodite.microunity.com> 

< 1994 10261 458.HAA23791@clio.microunity.com> 
From: doi@demeter (Derek Iverson) 
To: ericm@demeter 

Cc: tom@clio (Tom Laidig), tbr@aphrodite (Tim B. Robinson) 

Subject: Re: source repository 

Date: Wed, 26 Oct 1994 08:27:17 -0700 

I have included in this message the crib sheet I put together 
to give an overview of CVS, BOMs, and a few other issues and 
a copy of the README file that can be checked out from local/src. 
I would also recommend looking at the CVS man page. It should 
be considered a "man book' instead of a man page but it does 
have lots of good information. Also, there are man pages available 
for all the BOM related tools (as well as a -h command line option 
that gives a slightly shorter version). 

1 would also be more than happy to give a little ~ tutorial 1 on 
CVS and BOM related issues 

Derek 


Here is the crib sheet I put together 


Common CVS Commands and their Usage 

cvs checkout Check out sources from the repository into 

cvs co the local work area. The v co' and 'checkout' 


commands are synonymous. 


cvs add 


Tells CVS that you plan on adding a file or 
directory to the repository. 
If you are adding a file a commit is also 
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required. 


cvs remove 


Tells CVS that you plan on removing a file. 
(A removed file is actually put into an 1 Attic' 
A commit is required to complete the operation. 


cvs commit 
cvs ci 


Make any change to a file permanent. CVS 
will verify that you changes are derived 
from a current source before updating the 
repository. The 'ci* and 'commit* 
commands are synonymous. 


cvs update 


Update any local out-of-date sources from 
that found in the repository. 


cvs status 


Give me information about the file (both locally 
and in the repository) 


cvs log 


Print out any log messages supplied with 
previous commits (or check ins). 


cvs diff 


Show me differences between any two versions 
of a file. 


Bill OfMaterials-BOM 


BOM files provide us with a mechanism to identify specific files and 
subdirectories for later retrieval. 

Example BOM file: 

# Created by mkbom 

#$ld: BOM,v3.5 1994/01/18 13:57:07 LTtbrExp$ 


File 

1.1 

xheckoutrc 

File 

1.16 

Makefile 


File 

1.34 

Makefile, defs 

File 

1.44 

Makefile. rules 

Dir 

2.0 

BOM 

clockbias 

Dir 

5.0 

BOM 

compass 

Dir 

2.0 

BOM 

custom 

Dir 

2.0 

BOM 

dcell 

Dir 

2.0 

BOM 

doc 

Dir 

2.0 

BOM 

exlax 

Dir 

2.0 

BOM 

gards 

Dir 

2.0 

BOM 

gardswarts 

Dir 

3.0 

BOM 

ged 

Dir 

2.0 

BOM 

iss 

Dir 

6.0 

BOM 

leafgen 

Dir 

3.0 

BOM 

misc 

Dir 

2.0 

BOM 

motive 

Dir 

3.0 

BOM 

spice 

Dir 

2.0 

BOM 

verify 

Dir 

3.3 

BOM 

verilog 


BOM tools 
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releasebom Make, commit, and release a BOM. This tool will 
release all the checked in components for the 
specified directory (default is V) and all 
subdirectories (i.e. you release the directory tree 
rooted at the target directory). 

getbom Retrieves a BOM and extracts the contents specified by 
the BOM 

diffbom Shows the difference between two existing BOM files 
mkbom Makes a BOM file for the specific directory (used by 

releasebom - the normal user does not need to use this 

command). 

General Information 


Typical command sequence to release *new* files. 


cvs add filel file2 ... 

cvs commit filel file2 ... ** 

releasebom 

** You will see later on there are shortcuts offered by the 'commit' 
command that don't require you to type the names of the files 
you want to commit. Also, remember 'commit' and 'ci' are synonymous. 


Typical command sequence to release *modified* files. 


cvs commit filel file2 ... ** 
releasebom 

** You will see later on there are shortcuts offered by the 'commit' 
command that don't require you to type the names of the files 
you want to commit. Also, remember 'commit' and 'ci' are synonymous. 


How do I extract the contents specified by a BOM 


Suppose I wanted to extract the 'test' schematic found in proteus/ged/test 
according to BOM version 1 .4. Here are the steps. 

cd -/proteus/ged/test # I assume the directory already 
# exists. If not, create it. 

If the directory 'test' is already under CVS control (i.e. there is a 

CVS directory present and so the location of the BOM can be determined 

automatically). 

getbom -r 1.4 

Or, if the directory is not under CVS control (i.e. there is no CVS 
directory present) then you have to tell getbom where in the repository 
the BOM exists. 

getbom -r 1 .4 proteus/ged/test 

This will extract all the files and/or directories that are specified 
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by BOM version 1.4. 


How do I get a specific file that is in the cvs repository? 


The following command will extract a specific file. 

cvs checkout proteus/ged/ca/cabyte/spice_cn. 1 . 1 

This command will create a proteus directory (in the directory in which 
the command was executed), a ged directory within the proteus directory, 
a ca directory within the ged directory, a cabyte directory.... (I think 
you get the picture) and finally extract the specified file. 

The following command will extract an entire directory (in the same 
fashion as described above) except it will extract the entire 
directory tree (i.e. all files and subdirectories like cabit, 
cabitisrc, cabs Ids, cacasld, ...). 

cvs checkout proteus/ged/ca 

The following command will only extract all the files in the specified 
directory (in the same fashion as described above). This would include 
the files Makefile, Makefile. Spice, README, startup, concept base, and 
startup. ged. base if I was extracting the proteus/ged directory. 

cvs checkout -1 proteus/ged 


Once I have my files checked out, how do I update them to reflect any 
changes that may have occurred in the repository? 


cvs update filel file2 ... 

This command will either 

a. bring the specified files up-to-date 
with respect to what is found in the 
repository (i.e. no local mods) 

or 

b. merge any local modifications into 
the version found in the repository. 

♦note* If there is a conflict during the merge, the 

♦note* original file is saved as 

♦note* 

♦note* .^filename, vers ion 

♦note* 

♦note* in the current directory. 

cvs update -1 This command will perform the operation described 
above on all files in the local directory that 
are under CVS control. 

cvs update This command will perform the operation described 
above on all files in the local directory *and* 
all files in lower directories as well. 

cvs update -d The -d option will cause any new directories 
that have been added to the repository to also 
be extracted and updated. 
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The -d option is very useftil and can be done 
instead of using 'checkout' if you want to 
extract a directory that was previously excluded 
(or added to the repository) since the initial 
checkout. 


How do I find out the status of my local file? 


cvs status filel file2 ... 

Gives status information for each of the named files. 

cvs status -1 Gives status information for all files under CVS 
control in the current directory. 

cvs status Gives status information for all files under CVS 
control in the entire directory tree rooted at 
the current directory. 


What does using the CVS status command tell me? 


Here is the output of the command: 

cvs status /u/chip/proteus/Makefile.defs 


File: Makeflle.defs Status: Up-to-date 

Version: 1.51 Wed Feb 23 14:38:26 1994 

RCS Version: 1 .5 1 /p/cvsroot/proteus/Makefile.defs,v 

Sticky Tag: (none) 

Sticky Date: (none) 

Sticky Options: (none) 

Here is a description of all the little bits of info. 

File: You guessed it, the file name. 

Status: This tells you all sorts of info about the status 

of the file. The following describes the different 

status reports. 

Up-to-date The local file is identical the that found 
in the repository. 

Locally Modified 

The local file is derived from the same 
version that is found in the repository, 
but is is modified. 


Needs Checkout The local file is an older version from 
that found in the repository. 

Needs Merge The local file is derived from an older 
version than what is currently found in 
the repository, *and* it has local changes. 

Locally Added The file is staged to be added to the 
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repository on the next commit (or ci). 
This is the result of a 'cvs add' command. 

Locally Removed The file is staged to be removed from the 
repository on the next commit (or ci). 
This is the result of a 'cvs remove' command. 

Entry Invalid This means that since this file was checked 
out by you, someone else has used the 
cvs remove' command to remove the file 
from the repository. A future 'cvs update' 
will cause this file to be removed from your 
working area too. 

Unresolved Conflict 

This means that there is a file found 
locally (currently *not* under CVS control) 
that has the same name as a file that *is* 
under CVS control. 

Unknown The file is neither added to the repository 
or is found in the repository. 

Version: The version that the current file is derived from. 
RCS Version: The version of the file in the repository. 
Sticky Tag: This lets you 'attach' yourself to a specific 

version and will prevent you from getting any 

newer versions from the repository. 

This feature should only be used when a 'branch' 

is being used. 'Branches' will be described later. 
Sticky Date: This value is similar to what was described for 

a 'Sticky Tag' but in general we are not using this 

feature. 

Sticky Options: Same description as 'Sticky Date'. 

A useful alias that you might want to include in your shell startup 
files might be something like... 

alias status 'cvs status -1 1& egrep File:' 

alias allstatus 'cvs status |& egrep "ExamininglFile:"' 

The 'status' alias will give you the file name and status field for 
each of the file in the current directory. 

The 'allstatus' alias will the same information as status except it 
will include all the lower directory as well. 

(the '!&' means to put both stdout and stderr through the pipe) 


How do 1 cause a new directory xxschem in my existing checked out tree 
(~/proteus/ged/xx) to be added to the repository? 


What if this new directory also contains new files? 

cd ~/proteus/ged/xx Position yourself in the directory above 
the one you are about to add to the 
repository. 

cvs add xxschem CVS will ask if you really want to add 
this to the repository - the answer will 
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be yes. 


* now the directory has been added to the repository * 

cd xxschem Enter the directory so we can add the new 

files. 

cvs add body* spice* Tell CVS that you want to add the specified 
files to the repository on the next 
commit. 

cvs commit This will commit all the files that have 

been modified, marked for addition, or 
marked for deletion in the current 
directory tree. 


Can 'cvs commit' figure out what to do by itself? 


Yes. Here are some examples. 

cvs commit This will commit all files that have been 

modified, marked for addition, or marked 
for deletion in the entire directory 
tree. 

cvs commit -1 This will commit all files that have been 
modified, marked for addition, or marked 
for deletion in the current directory 
(not the entire tree). 

cvs commit filel file2 ... 

This will commit any changes, staged 
deletions, or staged additions of the 
specified files. 


How do I remove files from the repository. 


rm filel file2 ... Remove the files via a unix command first. 

cvs remove filel file2 ... 

Tell CVS that on the next commit, it 
should remove the named files from 
the repository. 

cvs commit filel file2 ... 

Commit the removal of the files from 
the repository, (cvs commit -1 may 
also have been used). 


If I 'cvs remove' and 'cvs commit' a file, is it gone forever? 


No. The file is actually moved into a directory in the repository 
called 'Attic'. This way you can still checkout a 'removed' file 
by using the '-r' option of update or checkout (-r lets you specify 
a specific revision number or tag). 
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♦NOTE* If you use the -r* option to extract a specific version 
of a file, the Sticky Tag will be set. If you want 
to later extract the latest version from the repository 
you will need to use the 'cvs update -A' commmand that tells 
CVS to override any Sticky Tag found. 

If you want to reinstate a removed file, there is no automatic way 
for this to occur. Please give me a call and I will help you 
un-remove' the file. 


How can I tell who made changes to a file? 


cvs log filename This command will list all the 
changes, the id of the person who 
made the changes, and the checking 
message that was supplied. This 
information is often quite lengthy 
so you may want to pipe it to 'more'. 


How can I find out what is different between my existing file 
and the one found in the repository. 


cvs diff filename This command will run Miff using 
your local file and the file in 
the repository ♦with the same version*. 

cvs diff -rl .7 filename 

This command will run 'diff using your 
local file and the file in the repository 
with version '1.7'. 

cvs diff -rl.7 -rl.8 filename 

This command will run 'diff on versions 
1 1 .7' and * 1 .8' of file name found in 
the repository. 

♦NOTE* there must not be a space between the V and the version! ! ! ! 
(cvs diff actually uses 'rcsdiff which doesn't like spaces 
between the version and the *-r'). 


How can I find out more info about these tools? 


There are man pages available for all the tools and 1 am always happy 
to answer any questions or help with any problems you might have. 


How can two people work on the same file most effectively? 


The cvs check-in/check-out process gives you interlocks, just not at 
the time that you check a schematic out. If two people are editing the 
same schematic at the same time, the first person who checks in their 
changes sees nothing different than normal. The second person, when 
attempting to check in their changes, is told (and prevented from 
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checkin in) that their local copy is no longer up-to-date with 
respect to the repository and they need to 'merge' their changes (i.e. 
find out what the other person did and make sure it is incorporated 
properly into your local schematic) before the commit is allowed. 
In this case, you find out at 'commit time* that someone else was 
editing the schematic at the same time. 

The 'cvs status 1 command will tell you at any time if you are working 
on the most recent copy of a schematic. If you are working in an area 
were it is common to have two people editing schematics at the same time, 
it would be wise to check the status of your local copy (ensuring 
it it derived from the most recent version) before embarking on any edits, 
then committing the changes as soon after the editing is complete by 
using 'cvs commit'. This way the chances of collisions is reduced 
enormously. 

An example of this process would be: 

cvs status file # check status before I edit. 

edit_tool„of_choice file # make my changes 
cvs commit # commit my changes 

This previous sequence may be repeated may times over many days.... 

releasebom # release it. 


What is a 'tag'? 


A 'tag' is simply a symbolic name attached to a particular version of 
a file. It is possible to assign a tag to any or all files within a 
directory (or possibly subdirectories). 

cvs tag tagname 

Recursively assigns the symbolic tag 'tagname' 
to all the local sources. 

cvs tag symbolic_tag filename 

Assigns the symbolic tag 'tagname' to the 
specified file name only. 

To extract a file with a tag, use the '-r* flag with the update or 
checkout commands. 

cvs update -r tagname 

Recursively update all directories so that they 
contain only files with the given tag. 
This means all other files that do not have the 
specified tag will be deleted from your local 
version! 

cvs update -r tagname filename 

Extract the version of the specified file name 
that corresponds to the tag 'tagname'. 


How do I delete a tag? 


A tag may be removed by using the '-d' option with the 'cvs tag' 
command. 
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Note: Be very careful when deleting a tag since this will effectively 
discard some historical information (i.e. a future extraction of the 
discarded tag will no longer include the file or files that had 
previously been marked with the tag). Do not remove a tag unless 
it is absolutely necessary. 

cvs tag -d tagname 

Recursively removes the symbolic tag 'tagname' 
from all the local sources. 

cvs tag -d tagname filename 

Same description as above except the tag is only 
removed from the specified file name. 


What is a 'branch'? 


A 'branch' provides the ability to commit changes to a given source file 
without requiring that the sources be up-to-date with respect to the 
latest revision of the file available on the 'trunk' (the main stream 
of development) but instead based on some previous version. 

The use of a 'branch tag' allows concurrent isolated development. 
Typically this is used for creating a patch to a previously released 
component or to allow for an experiment or special development 
on a particular component independent of the main stream development. 
Later, if the experiment succeeds, that development work can be 
merged into the trunk. 


How do I create and use a branch tag? 


A branch may be created and used by using the '-b' (branch) option 
with the 'cvs tag' command and then checking out (or updating) 
the sources with the newly created tag. 

Note: You need assign a branch *and* extract the files based on the 
branch tag in order to properly use a branch. 

cvs tag -b branch_tag (step 1) 

Recursively assigns the symbolic tag 'branch_tag' 
to all the local sources. 

cvs update -r branch_tag (step 2) 

Checks out all the sources with the tag ' branch tag' 
and ensures that future commits are based upon 
this branch instead of forcing changes to be 
up-to-date with respect to the trunk. 

cvs tag -b branch_tag filename (step 1) 
cvs update -r branch_tag filename (step 2) 

Same function as described above but only with 

respect to the specified file name. 

Future commits that occur on files that have been extracted (using 
the checkout or update commands) with a branch tag will all be based 
upon the original version of the file when it was made a branch. 
Future development on the trunk and the branch will be concurrent 
and independent. 
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What is the significance of the 1 Sticky Tags' that I see when I 
use 'cvs status' of a file that is either a branch or has been tagged? 


Any time a file is committed or extracted with a specific revision number 
or symbolic tag, a 'Sticky Tag' is set. This tag allows future 
commit, update, or checkout commands to always be relative to 
the version associated with the sticky tag. 

To override a sticky tag you may use the *-A' option with the 
update or checkout commands. This option will cause CVS to forget 
about specific versions and instead reference the 'head' (newest 
versions available on the trunk) revisions. 


How to incorporate changes made to a branch into the truck? 


If the changes that have been made to a branch are also wanted 
in the trunk, you may use the '-j* option of the update command 
to merge changes from a specified tag into the trunk. 

Note; You can not merge changes made on the mainline into a branch 
but you may instead merge changes from a branch into the mainline 
and you can also merge changes made in one branch into another. 

cvs update -j branchtag 

Recursively merge all changes made in the branch 
with the tag 'branchtag' with the current sources. 

There is a lot of stuff that I don't understand with regard to the 
use of the -j option. If you learn more, please teach me :-) 


########################################################################### 

mmmummmmmmmmmmmmmmmmnmmmmmmmmmmm 


Here is the README file 


The helper files Makefile.defs and Makefile.ru les are analogous to the 
files of the same names in proteus -- a typical tool Makefile would 
include Makefile.defs, then force some variable definitions, then 
include Makefile. rules. For example, a Makefile to install the shell 
script Too' and it's man page foo.l' would look like: 

CHIPROOT := $(shell abspath ../../..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

SCRIPTS = foo 
MANS = foo.l 

include $(CHIPROOT)/tools/src/Makefile.rules 


TTtTTTTrTTTTTiTTTTTTTTTTTT M I' J T t 

#####################* 




i ti i i tt ft it ir it jj ja 1111 111111414141414141 41 4444 44444444 41414444.11 
^WH~fTTTtrfTTTJT tttttt ffffffffTrffffrrirrrTffr/ rrrrrrff ffff ffffff 
14141111111414141 444441 it it tt ii fi tt if 11 it 44 444444 444144 4144444144 

^fr TT TT TT TTTT rTTTtTTTTT WiTTTTTjTtTTTTTTT TT TTTrTT TTTtTT TTTT TtWtT 

t44444444444444444444^&MMMl£MMiii£^ 
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If a directory contains multiple shell scripts, they can simply be 
added to the end of the SCRIPTS definition, and their man pages added to 
the MANS definition (if you have no man pages, don't bother defining 
MANS). (For this simple case, "gmake install-all' still does a build 
on every architecture. This doesn't hurt much, and I know how to fix 
it, but haven't gotten to it yet). 

If you have a C program (which can have a lex/yacc parser, as shown in 
this example), it's Makefile could be: 

CHIPROOT := $(shell abspath ../../..) 

include $(CHIPROOT)/tooIs/src/Makefile.defs 

EXEC = prog 
SCRIPTS = prog 

SOURCES = progmain.c utils.c parser.y scanner.l 
REFLIBS = tusk octmisc 
MANS = prog. 1 

include $(CHIPROOT)/tools/src/Makefile.rules 

This assumes that the current directory contains the following files: 

prog shell script wrapper for the program 

progmain.c a C source file 

utils.c another C source file 

parser.y the yacc parser 

scanner.l the lex scanner 

prog.l the man page 

The program will be linked with libtusk.a and liboctmisc.a (in that 
order), and the math library (I always add Mm' to the end of the link 
line). The token-definition file generated by yacc (which is normally 
included in the scanner) will be called 'parser.h*. Following the 
style I've developed, this Makefile will create the following hierarchy 
under the source directory: 

tools/src/prog/ 
sun4/ 
prog* 
parser.c 
parser.h 
scanner.h 
obj/ 

progmain.o 

utils.o 

parser.o 

scanner.o 

sgi/ 

(same as sun4) 
snake/ 
(same as sun4) 

Obligatory style comment: styles are fairly personal, and I won't make 
any attempt to convert people to this one. I like it because it 
separates the stuff for the different architectures and avoids 
cluttering the toplevel directory (this also means that you can say 
'cvs -n update' without being flooded with messages about derived 
files). If you prefer another style, I'm afraid you won't be able to 
use the Makefile.* I've set up. 
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These Makefile.* files can also install libraries. Here's tusk's 
Makefile (there's actually a bit more fluff involved in implementing a 
test suite, but this is the meat): 

CHIPROOT := $(shell abspath ../../..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

LIB = tusk 
HDRS = tusk.h 
MANS = tusk.3 

SOURCES = create. c queue. c byte.c reduce. c deferred. c accum.c \ 

boolean.c grow.c transform.c partition.c \ 

box.c polygon. c edge.c grid.c print.c memory .c 
REFLIBS = fang octmisc 

PRINTSRC := $(HDRS) tusk-int.h scan.h $(SOURCES) 

include $(CHIPROOT)/tools/src/MakefiIe.rules 

The HDRS macro lists header files to be installed in tools/include. 
The REFLIBS macro is only needed to support a target I didn't mention 
before: if you say "gmake saber-tusk" it'll emit the commands to 
load the source files and any needed libraries. The PRINT SRC macro is 
also only needed to support a target I didn't mention before: if you 
say "gmake printout" it'll format and print a copy of the source. 

The above examples only show a single library or executable being made 
and installed from one directory. If you have more than one of these, 
then you need to use the third helper file, Makefile. oneprog. This is 
because you need to define a different set of sources and reflibs for 
each. To show this, here's vlsimm's Makefile (again, with some testing 
fluff omitted). BTW, in the process of building these Makefile helpers, 
I suddenly found it was easy to do something Dan asked for a while ago: 
split out the vlsi I/O code as a separate library (which is now 
installed as libvlsi.a). 

CHIPROOT := $(shell abspath ../,./..) 

include $(CHIPROOT)/tools/src/Makefile.defs 

# 

# Build the vlsimm executable 
# 

EXEC = vlsimm 
SCRIPTS = vlsimm 

REFLIBS = $(ARCH)/libvlsimm.a $(ARCH)/libvlsi.a \ 

mebesout mebesread wap tusk octmisc udblib 
MANS = vlsimm. 1 

include $(CHIPROOT)/tools/src/Makefile.oneprog 
# 

# Build libvlsi.a 
# 

LIB = vlsi 
HDRS =vlsi.h 
SOURCES = vlsi.c 

include $(CHIPROOT)/tools/src/MakefiIe. oneprog 


Exhibit C7 


Page 655 of 703 


# Build libvlsimm.a 

# 

LIB = vlsimm 

SOURCES — vlsimm.c dataset.c iovlsi.c iomebes.c feature.c instr.c \ 
maskmod.c optimize.c subcell.c squares. c maskout.c \ 
yacc.y lex.l 

PRINT_SRC:= vlsimm.h vlsi.h format.h maskouth $(SOURCES) vlsi.c 

include $(CHIPROOT)/tools/src/Makefile.rules 

This Makefile installs two libraries and one executable. Note that the 
executable uses some libraries that are locally generated (and it gets 
them from the local area, so you can build the executable for testing 
without installing the libraries). There's some more flexibility here, 
primarily useful for testing: any entry in REFLIBS that ends in \a f is 
taken to be the unix path name of a library to be linked in; any other 
entry is taken to be the root name of a library that's installed in 
tools/lib/$(ARCH)/lib<name>.a. 


Stuff that I know needs work: 

As noted above, a Makefile that doesn't have to compile anything 
should not rsh to each machine in BUILD HOSTS to do an install. 

The man -page installation rule uses 'soelim', which doesn't exist 
on the sgi. This only causes trouble if an sgi machine is the first 
in the list of BUILD_HOSTS. 

There's no support for installing anything other than object 
libraries in tools/lib. 

There isn't much support for tools that can only be built on a 
subset of the available machine architectures. The one hack I put 
in is that if you define 'ARCH := ." after including 
Makefile. defs, it won't do any rsh'ing, but will just build on the 
current machine (which presumably will always be a sun). In this 
case, the architecture subdirectory gets collapsed into the main 
tool source directory. 


TomL. 

End of forwarded message — 
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From: tbr 

Sent: Saturday, October 29, 1994 3:16 PM 

To: 'bobm' 

Subject: forwarded message from Warren R. Ong 

Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["1271" "Wed" "26" "October" "94" "10:54:22" "PDT" "Warren R. Ong" "ong@ares " nil "31" "Re: Belated Netlist 
meeting notes" " A From:" nil nil "10"]) 
Return-Path: <ong@ares> 

Received: from demeter.microunity.com by gaea.microunity.com (4.1 /muse 1.3) 

id AA03149; Wed, 26 Oct 94 10:32:50 PDT 
Received: from ares.microunity.com by demeter.microunity.com (8.6.4/muse-sw.2) 

id KAA18043; Wed, 26 Oct 1994 10:54:24 -0700 
Received: from localhost by ares.microunity.com (8.6.4/muse-sw.2) 

id KAA25729; Wed, 26 Oct 1994 10:54:23 -0700 
Message-Id: <199410261754.KAA25729@ares.microunity.com> 

In-Reply-To: <199410220413.VAA29317@demeter.microunity.com>; from "Tim B. Robinson" at Oct 21, 94 9:13 pm 
X-Mailer: ELM [version 2.3 PL1 1] 
From: ong@ares (Warren R. Ong) 
To: tbr@demeter (Tim B. Robinson) 

Cc: bill@aphrodite, dickson@demeter, ong@aphrodite, wayne@mercury 
Subject: Re: Belated Netlist meeting notes 
Date: Wed, 26 Oct 94 10:54:22 PDT 

>From Tim B. Robinson ... 

@ 
@ 

@ Warren R. Ong wrote (on Fri Oct 21): 
@ 

@ There are 2 bellybuttons in each iobyte, one bellybutton is 

@ controlled by vff/vrr and the other one is controlled by vffc/vrrc. 

@ To completely shut off current in iobyte would require setting all 

@ pins of vffI2:0] and vffc[2:0] to vdde (and I guess vrr[2:0] and 

@ vrrc[2:0] to vdde - Ov @ OuA). Bill thinks that there is a 

@ Cerberus setting to do this. I had thought there might have been 

@ an issue with gate punch through, but this is not an issue since 

@ the punch through voltage is 3.6V. 

@ 

@ Cerberus provides 3 bits to set the current level, bits 56:54 in 
@ octlets 32 and 33 (for channels 0 and 1 respectively). Can you check 
@ with rich dickson that this field is indded wired such that a zero 
@ value will cut the current to zero. 

@ 

After Rich navigated through the verilog files, it appears that 
the 3 bits controlling the output current needs to be HIGH in 
order to shut the output current off. (The controlling signal in 
iobyte is CSEL_ABM[2:0]. This needs to be high to shut off the 
output current.) 

The opposite polarity is needed to shut off the load resistor. 
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RSOURCE_ABM[2:0] needs to be low to turn off the termination 
resistors. 

Warren. 

End of forwarded message 
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From: 


tbr 


To: 


Subject: 


Sent: 


Saturday, October 29, 1994 3:45 PM 
'Geert Rosseel' 
Re: What I need 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Oct 29): 

sounds good tome.. 
OK, here's what I have left after a successful run: 

tbr@aphrodite ~/euterpe/verilog/bsrc/cdio 425 % Is *base* 
cdio-base.netcap cdio-base.pim cdio-base.strength 

cd io-base . ordered . all .nets cdio-base.power .tab .local cd io-base .xr f 
cdio-base. ordered, short.nets cdio-base.short.nets 

I think that covers everything. 


Tim 


Exhibit C7 


Page 659 of 703 


Subject: 


From: 


Sent: 


To: 


tbr 

Saturday, October 29, 1994 7:38 PM 
'paulb' 

forwarded message from tbr 


Follow Up Flag: Follow up 
Flag Status: Red 

This is the mail I think you never got. . . 

Start of forwarded message 

To: pandora 
cc: paulb 

Subject: Belated meeting notes 


Some notes from a meeting last week. 

Gmo has found that the vendor of choice for PCI SCSI controllers 
is Bus Logic. This is based on discussions on the net and from notes 
inthe Linux distribution which say it's the only one to consider. 

There is no corresponding clear choice for RGB and Ethernet. 

No serial interfaces have come to light so far. 

Action: gmo to work with wkm to get more data and technical manuals 
on a selection of boards. 


gmo reported it will cost $40K to upgrade our OSF license to V 1 .2.2 
(A further redistribution fee of $35K would have to be payed before we 
can ship products using it.) After a brief discussion it was agreed 
OSF is still the correct choice. 


Mouss noted that Tony Stelliga may have contacts with PCI experience. 
Action: tbr to ask tony for contacts. 


Vandyke has already ordered a second Pentium nachine for PCI driver 
development. 

The speclnt 92 benchmarks have compiled OK with the latest compiler. 
Spec89 will be compiled soon. The IEEE fp emulation package is being 
dusted off to allow the specFP set to be run. 


Next meeting Friday 3 pm 


Tim 


End of forwarded message 
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Subject: 


From: 


Sent: 

To: 

Cc: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, October 29, 1994 7:54 PM 
'hestia@aphrodite' 

'pmayer@aphrodite'; 'albers@aphrodite'; 'tbr@aphrodite'; 'philip@aphrodite' 
prt review 


Notes from the main board prt review 

1. All SMT components need pad dimensions checking. The PCAD report does not include 
this information. It will have to be checked on screen. Since glen built all these 
parts, pmayer will do the onscreen check so it's independent. 

Action: pmayer to check pad dimensions for all the SMT parts in this batch 


2. pmayer noted that PCAD requires an explicit upodate if a library part is changed. 
Since there have been so many changes it would be worth investigating if there is a way to 
re-read the entire library. 

Action: tbr to ask albers to check if we can do a global update. If not, pmayer will 
update components individually. 


3. It would be helpful for pmayer to receive the checkin notices for the library. 
Action: tbr to have torn add her to the distribution. (Done) 


4. pl00_00005, pll0_00028 

These parts do not have pin 1 distinguished by pad shape. 
Action: pmayer to correct. 


5 . pllO_Q0029 

There was confusion over the preferred vendor for this part. The database has National, 
but according to yves it's not in their data book. 

Action: philip to resolve preferred vendor. 


6. pll0_00031 

The hole size is too large and could alow the shouldered portion of the leads to drop 
right into the board. Hole size to be reduced 5 mils. New padstack is 

pin 1 113 
pin 2 114 

pin 3 114 

Action: pmayer to correct. 


7. pl40_00010 

Pin 2 needs to be pad type 114 {round pad) . 
Action: pmayer to correct. 


8 . pl80_00004 

Some ground vias need position adjustment. 
Action: pmayer to correct. 
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9, p210_00023 / p210_00024 

Pin 1 needs silk screen polarity indicator. Pins are reversed in .prt file. 
Action: pmayer to correct. 

Tbr had to leave the meeting at this point. Woody will post notes on on remaining issues. 
Tim 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Saturday, October 29, 1994 7:56 PM 

Vanthof 

'sysadmin' 

topt core dump 


Follow Up Flag: Follow up 
Flag Status: Red 

I got a core dump from topt. This was after it complained of a write 
error. However, there plenty of free space at the time: 

Warning! No RD_BM<4> pin capacitance data for cgclockbias 
Warning! No RD_BM<3> pin capacitance data for cgclockbias 
Write Failure! The disk may be full. 

Closing off log file. No more status will be recorded 
/bin/sh: 3668 Memory fault - core dumped 
make[4]: *** [gards/ioO-iter] Error 1 

make[4]: Leaving directory '/N/auspex/roo^l/euterpe-snapshot/euterpe/verilog/bsrc/io' 
make[3J: *** [gards/ioO-iter] Error 1 

make[3]: Leaving directory ^/N/auspex/roo^l/euterpe-snapshot/euterpe/verilog/bsrc/io' 
make[2]: *** [gards/ioO-iter] Error 1 

make[2]: Leaving directory 4 /N/auspex/root/s41/euterpe-snapshot/euterpe/verilog/bsrc/io' 
make[l]: *** [gards/ioO-iter] Error 1 

make[l]: Leaving directory '/N/auspex/roo^l/euterpe-snapshot/euterpe/verilog/bsrc/io' 
make: *** [ioOgards] Error 1 

tbr@mothra /n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/io 410 % df. 
Filesystem kbytes used avail capacity Mounted on 
auspex3:/s41 1847292 1259670 495257 72% /N/auspex/root/s41 
tbr@mothra /n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/io 41 1 % cname 
topt 


Tim 
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From: vant [vanthof@hestia] 

Sent: Saturday, October 29, 1994 8:00 PM 

To: 'Tim B. Robinson' 

Cc: Vanthof@aphrodite'; 'sysadmin@aphrodite' 
Subject: Re: topt core dump 

Tim B. Robinson writes: 

> 
> 

>I got a core dump from topt. This was after it complained of a write 
>error. However, there plenty of free space at the time: 

topt will only give that particular message when it gets a failure from 
an fprintf to the stat file. Something somewhere indicated to the program 
via the fprintf library call that it failed on a write. 

If you haven't tried to do so yet, I'd recomend trying again. That would 
be the first thing I would need to do anyway to try and track this down. 

Thanks, 
Dave 

> 

>Warning! No RD_BM<4> pin capacitance data for cgclockbias 

>Warning! No RD_BM<3> pin capacitance data for cgclockbias 

> Write Failure! The disk may be full. 

> Closing off log file. No more status will be recorded 

>/bin/sh: 3668 Memory fault - core dumped 

>make[4]: *** [gards/ioO-iter] Error 1 

>make[4]: Leaving directory '/N/auspex/root's41/euterpe-snapshot/euterpe/verilog^src/io' 
>make[3]: *** [gards/ioO-iter] Error 1 

>make[3]: Leaving directory s /N/auspex/root/s41/euterpe-snapshot/euterpe/verilog/bsrc/io' 
>make[2]: *** [gards/ioO-iter] Error 1 

>make[2]: Leaving directory '/N/auspex/TOo^l/euterpe-snapshot/euterpe/verilog/bsrc/io' 
>make[l]: *** [gards/ioO-iter] Error 1 

>make[l]: Leaving directory , /N/auspex/root/s41/euterpe-snapshot/euterpe/verilog/bsrc/io' 
>make: *** [ioOgards] Error 1 

>tbr@mothra /n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/io 4 10 % df . 

>Filesystem kbytes used avail capacity Mounted on 

>auspex3:/s41 1847292 1259670 495257 72% /N/auspex/root/s4 1 

>tbr@mothra /n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/io 41 1 % cname 

>topt 

> 

> 

>Tim 

> 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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From: Tom Laidig [tom@clio] 

Sent: Sunday, October 30, 1994 12:49 PM 

To: 'Geert Rosseel' 

Cc: 'geert@aphrodite'; 'tbr@aphrodite'; 'tom@aphrodjte'; 'wampler@ambiorix' 

Subject: Re: baseplate problem 


Geert Rosseel writes: 
Tim says : 


I cannot seem to get a stripped down top level past pcomp. I ahve 
updated by baseplate and I'm sure I have the latest, yet I get: 

... PHYSICALLIB:PBUILD; 
. . . Processing rest of user PDL. 
in XBHRDF32S at line 49667: 
--> CELL:E41X1; 

! 

** Syntax Error: Unrecognized keyword: E41X1. 
(Message number 2 3 Severity 5) 

... Processing rest of system PDL. 

. . . Processing TDL. 

... TECHNOLOGYLIB : SOFA; 

. . . Computed Grid_Size = 10 00 

. . . Final Processing. 

1 fatal errors occured. PCOMP aborting. 


Can this be the old problem taht we have to pre-define allowable sizes 
in the * . cdl file. I looked in there and there is no definition for the 
E41X1 cell. 

Kurt : do we have to re-run the gards-model generation to get this ? 

The file CHIPROOT/gards/sofa/sof a . cdl definitely needs to be up to date (which is 
accomplished by running make in CHIPROOT/gards) , but I'm confused by a couple things. Tbr 
didn't mention what directory he was working in, so I'm assuming 

~tbr/euterpe/verilog/bsrc/<something>. The above-mentioned file was regenerated last 
night, and definitely doesn't include E41X1. On the other hand, nor does xbhrdf32s 
require it! From /u/chip/proteus/gards/leaf /xbhrdf 32s . pdl (which is what tbr 1 s proteus 
ends up getting) : 

PHYSICALNAME : XBHRDF32S; 
CELL : E23X1,- 

Can someone shed some light on what I should really be looking at? 


Tom L 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Sunday, October 30, 1994 12:58 PM 
To: 'tom@clio' 

Cc: 'geert@aphrodite'; 1br@aphrodite'; 'torrKgaphrodite'; 'wampler@ambiorix' 
Subject: Re: baseplate problem 

Hi 

I believe Tim is working from the euterpe snapshot in /s41 
Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Sunday, October 30, 1994 1:01 PM 

'Geert RosseeP 

'geert@aphrodite'; 'tbr@aphrodite'; 'tom@aphrodite'; 'wampler@ambiorix' 
Re: baseplate problem 


Geert Rosseel writes: 


| Hi 


j I believe Tim is working from the euterpe snapshot in /s41 
Well, that doesn't explain it to me either: 
-> grep PHYSICAL 

/n/auspex/s41/euterpe-snapshot/euterpe/proteus/gards/leaf /xbhrdf 32s .pdl 
PHYSICALLIB : PBUILD; 
PHYSICALNAME : XBHRDF3 2S; 
END PHYSICAL; (* XBHRDF3 2S *) 


- > 


Tom L 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Sunday, October 30, 1994 1:12 PM 

'Tom Laidig' 

, geert@ambiorix , ; 'geert@aphrodite'; 'tbr@aphrodite'; , tom@aphrodite'; 'wampler@ambiorix' 
Re: baseplate problem 


Tom Laidig writes : 


Geert Rosseel writes: 


Hi 


I believe Tim is working from the euterpe snapshot in /s41 
Well, that doesn't explain it to me either: 
-> grep PHYSICAL 

/n/auspex/s41 /euterpe- snapshot /euterpe/proteus/gards/ leaf /xbhrdf 32s .pdl 

| PHYS ICALLIB : PBUILD ; 

| PHYS I CALNAME : XBHRDF3 2S; 

| END PHYS I CAL ; (* XBHRDF32S *) 


Oh, I just read this... after seeing the right information, I carefully set up the wrong 
grep and dutifully cut and pasted the results into the window without reading them. 
*sigh* Try this instead: 

-> grep CELL 

/n/auspex/s41 /euterpe -snapshot /euterpe/proteus/gards /leaf /xbhrdf 3 2s .pdl 
CELL : E2 3X1; 


So where's the E41X1 thing coming from? 


Tom L 
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From: Geert Rosseel [geert@rhea] 

Sent: Sunday, October 30, 1 994 2:05 PM 

To: 'geert@rhea' 

Subject: pager log, sender copy 


page from geert to geert : 

pageme gmake gards/geert_euterpe-iter .garout . lis start :Oct_30_10 : 59 end: 
Oct 30 11:03 exit 0 


Exhibit C7 


Page 669 of 7 


From: Geert Rosseel [geert@ambiorix] 
Sent: Sunday, October 30, 1 994 2:07 PM 
To: 'tb^ambiorix'; Vampler@ambiorix' 
Subject: Another gards-limit 


FILES FOR THIS ENTIRE RUN: 

DESIGN FILE: geert_euterpe-iter.dff 

LISTING: geert_euterpe-iter.garout.lis 

CONGVAL: padobs.cvp 

STRATEGY: geert_euterpe-iter.rcf 
**GAROUT error: 68 

The 'NETLIST parameter is set more than 20 times in the RCF file. 
Severity 7 is fatal. 

*** ERROR 68 IN RSTRAT *** SEVERITY 7 

Probable User Error 

For further help contact your customer support representative. 


I am using a whole bunch of sepearte netlist files to route the top-level. 
That makes it esay for me to split up different busses in different files and 
route them is different order with different routing strategies. 

I can get around this by "cat" -ting different files together, but 
that is not as convenient. 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Karzes [karzes@MicroUnity.com] 
Sunday, October 30, 1994 8:55 PM 
*mws@MicroU nity.com' 

'abbott@M icroUnity.com'; 'fur@MicroUnity.com'; 'dickson@MicroUnity.com' 
gextract128 


> I don't know. Dickson had me do 3 issues, but I don't know what his 

> unit is doing with them except that he bypasses from 1st to 2nd and 

> 2nd to 3rd. 

As far as I was aware the euterpe spec called for all gextracts to take 2 issue slots, 
12 8 -bit or otherwise. If gextractl28 is going to take 3, that's a spec change which has 
software ramifications and therefore, in my opinion, needs to be agreed upon. How about 
128 -bit immediate gextracts? 

How about < 12 8 -bit gextracts? I assume that the < 128 -bit gextracts only take 2 slots. 
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From: tbr 

Sent: Sunday, October 30, 1994 8:57 PM 

To: 'Tom Laidig' 

Cc: 'Geert Rosseel'; 'geert@aphrodlte'; 'torr^aphrodite'; ^ampler@arnbiorix' 

Subject: Re: baseplate problem 
Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Sun Oct 30): 
Geert Rosseel writes: 
j Tim says : 


jl cannot seem to get a stripped down top level past pcomp. I ahve 
| updated by baseplate and I'm sure I have the latest, yet I get: 

|... PHYSICALLIB:PBUILD; 
|... Processing rest of user PDL. 
jln XBHRDF32S at line 49667: 
|-> CELL:E41X1; 

|** Syntax Error: Unrecognized keyword: E41X1. 
((Message number 23 Severity 5) 

j... Processing rest of system PDL. 
j... Processing TDL. 
j... TECHNOLOG YLIB : SOF A ; 
j... Computed Grid_Size = 1000 
j... Final Processing. 

1 fatal errors occured. PCOMP aborting. 


j Can this be the old problem taht we have to pre-define allowable 
jsizes in the *.cdl file, I looked in there and there is no definition 
|fortheE41Xl cell. 

j Kurt : do we have to re-run the gards-model generation to get 
jthis ? 

The file CHIPROOT/gards/sofa/sofa.cdl definitely needs to be up to date 
(which is accomplished by running make in CHIPROOT/gards), but I'm 
confused by a couple things. Tbr didn't mention what directory he was 
working in, so I'm assuming ~tbr/euterpe/verilog/bsrc/<something>. The 
above-mentioned file was regenerated last night, and definitely doesn't 
include E41X 1 . On the other hand, nor does xbhrdf32s require it! From 
/u/chip/proteus/gards/leaff xbhrdf32s.pdl (which is what tor's proteus 
ends up getting): 


PHYSICALNAME : XBHRDF32S; 
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CELL :E23X1; 


Can someone shed some light on what I should really be looking at? 

You are in the right place in my tree, and yes I did rebuild it. 

I had the problem, assumed by gards model was out of date, remade my 

baseplate and gards model and tried again. Same result. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Sunday, October 30, 1994 8:57 PM 

To: Tom Laidig' 

Cc: 'Geert Rosseel'; 'geert@aphrodite'; 'torn ©aphrodite'; 'wampler@ambiorix' 

Subject: Re: baseplate problem 


Tom Laidig wrote (on Sun Oct 30) : 
Geert Rosseel writes : 
Tim says : 


I cannot seem to get a stripped down top level past pcomp. I ahve 
updated by baseplate and I'm sure I have the latest, yet I get: 

. . . PHYSICALLIB : PBUILD ; 
... Processing rest of user PDL. 
In XBHRDF32S at line 49667: 
CELL :E4 1X1; 

j 

** Syntax Error: Unrecognized keyword: E41X1. 
(Message number 2 3 Severity 5) 

. . . Processing rest of system PDL. 

. . . Processing TDL. 

... TECHNOLOGYLIB: SOFA; 

. . . Computed Grid_Size = 1000 

. . . Final Processing. 

1 fatal errors occured. PCOMP aborting. 


Can this be the old problem taht we have to pre-define allowable 
sizes in the *.cdl file. I looked in there and there is no definition 
for the E41X1 cell. 

Kurt : do we have to re -run the gards -model generation to get 
this ? 

The file CHI PROOT/ gards /sof a/sofa . cdl definitely needs to be up to date 
(which is accomplished by running make in CHI PROOT /gards) , but I'm 
confused by a couple things. Tbr didn't mention what directory he was 
working in, so I'm assuming ~tbr/euterpe/verilog/bsrc/<something> . The 
above-mentioned file was regenerated last night, and definitely doesn't 
include E41X1. On the other hand, nor does xbhrdf32s require it J From 
/u/chip/proteus/gards/leaf /xbhrdf 32s .pdl (which is what tbr's proteus 
ends up getting) : 

PHYS I CALNAME : XBHRDF32S; 
CELL : E23X1; 

Can someone shed some light on what I should really be looking at? 

You are in the right place in my tree, and yes I did rebuild it. 

I had the problem, assumed by gards model was out of date, remade my baseplate and gards 
model and tried again. Same result. 

Tim 
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From: tbr 

Sent: Sunday, October 30, 1 994 8:58 PM 

To: 'Geert Rosseel' 

Cc: 'geert@aphrodite'; 'tom@aphrodite'; 'tom@clio'; , wampler@ambiorix' 

Subject: Re: baseplate problem 
Follow Up Flag: Follow up 

Flag Status: Red 

Geert Rosseel wrote (on Sun Oct 30): 
Hi 

I believe Tim is working from the euterpe snapshot in /s4 1 

Not for the top level run. 1 was actually trying to test the changes 
I made in Makefile.tst in my local area before checking it in. 
I have only been touching the sub-blocks in the snapshot area. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Sunday, October 30, 1994 8:58 PM 

To: 'Geert Rosseel' 

Cc: 'geeiKgaphrodite'; 'tom@aphrodite'; 'tom@c!io'; 'wampler@ambiorix' 

Subject: Re: baseplate problem 


Geert Rosseel wrote (on Sun Oct 30) : 
Hi 

I believe Tim is working from the euterpe snapshot in /s41 

Not for the top level run. I was actually trying to test the changes I made in 

Makefile. tst in my local area before checking it in. 

I have only been touching the sub-blocks in the snapshot area. 

Tim 
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To: 


From: 


Sent: 


tbr 

Sunday, October 30, 1994 10:33 PM 
'dicksorY 


Subject: 


csyn errors 


Follow Up Flag: Follow up 
Flag Status: Red 

Please take a look in: 

tbr@gamorra~/euterpe/verilog/bsrc 410 % Is -Is *.csyn 

296 -rw-rw-r- I tbr 294327 Oct 30 1 9:3 1 tbrj?uterpe-pass 1 .csyn 

This is a csyn run against the latest stuff. 


Tim 
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From: Kurt Wampler [wampler@thoas] 

Sent: Monday, October 31, 1994 1:21 AM 

To: 'geert@ambiorix'; 'geert@aphrodite'; 'tbr@aphrodite'; 'tom@aphrodite' 

Subject: Re: baseplate problem 


> Tim says 


>I cannot seem to get a stripped down top level past pcomp. I ahve 
> updated by baseplate and I'm sure I have the latest, yet I get: 
> 

> . . . PHYSICALLIB : PBUILD ; 
>... Processing rest of user PDL. 
>In XBHRDF32S at line 49667: 
>--> CELL:E41X1; 

> ! 

>** Syntax Error: Unrecognized keyword: E41X1. 

> (Message number 23 Severity 5) 

> 

>... Processing rest of system PDL. 

>. . . Processing TDL. 

> . . . TECHNOLOGYLIB : SOFA; 

>... Computed Grid_Size = 1000 

>... Final Processing. 

> 1 fatal errors occured. PCOMP aborting. 


> Can this be the old problem taht we have to pre-define allowable sizes 
>in the *.cdl file. I looked in there and there is no definition for the 
>E41X1 cell. 

> 

> Kurt : do we have to re -run the gards -model generation to get this ? 


After reading the flurry of traffic logged earlier today, I offer 
the following: 

The file : /u/tbr/euterpe/verilog/bsrc/gards/tbr2_euterpe-itermacros .pdl 
looks potentially stale; it is dated September 14. 

Yet, when I check the date on: 

/u/tbr/euterpe/proteus/gards/leaf /xbhrdf 32s .pdl, it shows a date of 
October 18, and has an internal size of E23X1. 

Seems to me like the tbr2_euterpe- itermacros .pdl needs to be deleted 
and a fresh copy constructed from the current PDL's. Hmmm, I wonder 
why the dependencies in the Makefile didn't trigger this automatically? 

- Kurt 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Monday, October 31 T 1994 1:32 AM 

To: 'Kurt Wampler' 

Cc: 'geert@ambiorix'; 'geert@aphrodite'; , tom@aphrodite , 

Subject: Re: baseplate problem 


Kurt Wampler wrote (on Sun Oct 30) : 
> Tim says : 


>I cannot seem to get a stripped down top level past pcomp. I ahve 
> updated by baseplate and I'm sure I have the latest, yet I get: 
> 

> . . . PHYSICALLIB: PBUILD; 

>. . . Processing rest of user PDL. 
>In XBHRDF32S at line 49667: 
>--> CELL:E41X1; 

> J 

>** Syntax Error: Unrecognized keyword: E41X1. 

> (Message number 23 Severity 5) 

> 

Processing rest of system PDL. 
Processing TDL. 
TECHNOLOGYLIB : SOFA; 

Computed Grid_Size = 1000 
Final Processing. 

1 fatal errors occured. PCOMP aborting. 


> Can this be the old problem taht we have to pre-define allowable 
>sizes in the * . cdl file. I looked in there and there is no definition 
>for the E41X1 cell. 

> 

> Kurt : do we have to re -run the gards- model generation to get 
>this ? 


After reading the flurry of traffic logged earlier today, I offer 
the following: 

The file: 

/u/tbr/euterpe/verilog/bsrc/gards/tbr2_euterpe- itermacros . pdl 
looks potentially stale; it is dated September 14. 

Yet, when I check the date on: 

/u/tbr/euterpe/proteus/gards/leaf /xbhrdf 32s .pdl, it shows a date of 
October 18, and has an internal size of E23X1. 

Seems to me like the tbr2_euterpe- itermacros .pdl needs to be deleted 
and a fresh copy constructed from the current PDL's. Hmmm, I wonder 
why the dependencies in the Makefile didn't trigger this automatically? 

This is probably the cause, though I'm at a loss to explain why that file ahs not been 
remade. The makefile does not have dependencies on the individual pdl ' s . The reason is 
it takes make about 15 minutes to figure out it has no rules to remake the pdl's. We 
commented out that dependency. What's really needed is a terminal dependency that would 
stop it even trying to remake them. 

However, the macros. pdl file does of course depend on the design itself so it should have 
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remade because of that . 

I'll investigate further . . . 
Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Monday, October 31, 1994 9:54 AM 

'Geert Rosseel'; 'Dave Van't Hof 

Thomas Laidig' 

Re: missing layout file(s) 


I was doing some cleanup on Friday, and deleted "mobiwaf f le ' , which looks kind of 
obsolete, and certainly isn't used in calliopel or euterpe. 
However, it is called out in the cells 

padtest 

padsig 

padtestvdd 

padtestvss 

padtestvdda 

Maybe these are from pollux? I dunno. Anyway, I restored mobiwaffle, so you should stop 
getting the nastygrams from chip. 


ooooO Ooooo 


| ( Tom ) | 

(_) L (_) 
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From: vant [vanthof@hestia] 

Sent: Monday, October 31, 1 994 9:58 AM 

To: Tom Laidig' 

Cc: 'geert@clio'; 'vanthof@clio'; f tom@clio' 

Subject: Re: missing layout file(s) 


Tom Laidig writes: 
> 

>I was doing some cleanup on Friday, and deleted "mobiwaf f le ' , which 
>looks kind of obsolete, and certainly isn't used in calliopel or euterpe . 
>However, it is called out in the cells 
> 

> padtest 

> padsig 

> padtestvdd 

> padtestvss 

> padtestvdda 
> 

>Maybe these are from pollux? I dunno. Anyway, I restored mobiwaffle, 
>so you should stop getting the nastygrams from chip. 


> ooooO Ooooo 
( J (_ ) 

> | ( Tom ) | 
(_) L (__) 


Thanks ! 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! (tm> All kids love Log! #incluce 
<std_disclaim . h> 
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Cc: 

Subject: 


From: 
Sent: 
To: 


Kurt Wampler [wampler@thoas] 
Monday, October 31, 1994 12:16 PM 

'al@thoas'; 'cadettes@thoas'; 'fung@thoas'; 'geert@thoas'; 'mudge@thoas'; 'paulp@thoas'; 

'tbr@thoas' 

'wampler^hoas' 

Re-animate twinvia program? 


This is a call for general opinion. Please forward to anyone I may have inadvertently 
left off of the address list that you know would have an interest in this question. 

Back in Roller days, we had a back-end CAD program called "twinvia" which crawled through 
GARDS- generated routes and converted minimum single vias to double via structures, with 
the basic goal of improving yield. When we made the move to MOBIMOS design rules, early 
opinions that I received were ambivalent about the usefulness of this technique, and the 
twinvia program was put in mothballs. (In MQBI, the program just elongates the vias, but 
the basic idea is the same a minimum 0 . 5x0 . 5uM via is converted to a rectangular 
0 . 5x1 . 5uM via wherever possible . ) 

Last week, I ran an experiment on the Calliopel top-level route, and the twinvia program 
had a little better than a 90% success rate at converting minimum square V23 & V34 
structures into elongated vias. Runtime on a SPARC- 10 was about 45 minutes. (It can't 
treat V12 ' s right now because of a GARDS modelling deficiency.) 

So, to put the question: given the experience we have so far with minimum square metal 
features in MOBIMOS, would it be helpful to deploy this program as part of the standard 
tapeout flow? (Keep those eggs & tomatoes at less than Mach 1, please.) 


Kurt 
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From: John Campbell [solo@echidna] 
Sent: Monday, October 31 , 1 994 12:43 PM 
To: 'Kurt Wampler' 

Cc: 'John Campbell'; 'Albert Matthews'; 'cadettes@echidna'; 'Fung Chen'; 'Geert Rosseel'; 'john mudge'; 
'Paul Poenisch'; Tim B. Robinson' 

Subject: Re: FWD: Re-animate twinvia program? 
as Kurt Wampler was saying 

..So, to put the question: given the experience we have so far with minimum 
..square metal features in MOBIMOS, would it be helpful to deploy this program 
..as part of the standard tapeout flow? (Keep those eggs & tomatoes at less 
..than Mach 1, please.) 

..- Kurt 


I am a firm believer that if you can open a .5 x .5 via 99.999 % of 
the time, that you can open one out of two 99.99999999 % of the time. 

I think a .5 x 1.5 has as good a chance as two .5x.5 or better. 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Monday, October 31 , 1994 12:47 PM 
To: 'admin@MicroUnity.com' 
Subject: disk usage report 

For directories over 100 megs: 
user's info: 


brianl 

1 148 

hopper 

1 ACQ 

two 

IVuo 

chip 

yoo 

geert 

oyj 

craig 

8 fid 

dickson 

/OH 

rozen 

~JA£L 
/40 

jsw 

OOH- 

vanthof 


tor 

Kin 

gmo 

^ 1 1 

brendan 

479 

sandeep 

471 

n 

AAA 

rocky 


qua 

A1K 

vijay 

425 

brian 

417 

tur 


w ampler 

353 

ken 

1AQ 

age 

iZI 

Knp 

IRS 

L„L„ 

henu 

2o 1 

tbe 

279 

bfox 

268 

torn 

268 

bpw 

zoo 

ras 

lit 

Zjj 

doi 

228 

cox 

0 1 o 
ziy 

rung 

219 

veena 

209 

guarino 

208 

peter 

206 

bill 

195 

rich 

195 

haim 

190 

lisar 

189 

hessam 

188 

iimura 

188 

al 

181 

mws 

179 

ericm 

178 

jeffm 

174 

vandyke 

173 

solo 

162 

billz 

161 
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lisa 

146 

randy 

142 

jeff 

139 

hayes 

137 

paulb 

136 

karzes 

136 

woody 

134 

wingard 

131 

octtools 

130 

gregg 

128 

joe 

125 

tomho 

125 

dane 

117 

ierrv 

115 

ong 

112 

larryk 

112 

yves 

111 

chuck 

110 

abbott 

108 

fambro 

108 

albers 

105 


packages info: 
chip-euterpe-buil 1755 
calliope 1579 
news 1394 
euterpe-verify 1030 
stb-build 916 
chip-proteus 905 
chip-archive 859 
orchissnap 811 
calliope-disk2 730 
soft-src 637 
cadence 606 
ptolemy 605 
sun 583 
archives 545 
losf-build 513 
bigtmp 494 
calliope 1-fractur 487 
chip-calliope 484 
chip-terpsichore 475 
sgi 439 
soft 414 
xllr5_ken_p26 329 
castor-retry 325 
bosf-build 323 
chip-archive-terp 318 
calliope-overflow 297 
mips-4.52 282 
osf 260 
chip-archive-mnem 259 
Xllr4 228 
bsd 222 
cadencedoc 221 
synopsys 216 
cadence. hp 216 
cadence_doc_9402 215 
budtool_db 190 
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Motif 

177 

iimura.be 

171 

budtool 

166 

mechanica 

164 

sgi5 

152 

ucberl 

147 

vlsi.v8r4_2 

145 

proe_13.0 

138 

proe tmp 

138 

khoros 

134 

ibes backup 

134 

calliope- verify 

132 

gnu 

125 

bsd43 

115 

frame-4.0.3 

114 

svr4 

114 

Xllr5 

110 

chip-mdunit 

101 

motifl.2 

101 


machine user megs package megs total megs max capacity %used 

auspex 19617 18917 38535 63434 60% 

rama 3493 2591 6085 9428 64% 

rhea 206 1598 1805 2484 72% 

gaea 12 1753 1765 1780 99% 

cronus 602 2202 2805 6208 45% 

auspex rama rhea gaea cronus: 

23930 27061 50995 83334 61% 
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From: vant [vanthof@hestia] 

Sent: Monday, October 31, 1994 1:46 PM 

To: Tim B. Robinson'; 'Lisa Robinson'; 'Tom Vo'; 'Mark Hofmann'; 'Geert Rosseel' 

Cc: 'Dave Van't Hof ; 'Kurt Wampler'; 'Thomas Laidig' 

Subject: euterpe baseplate drc errors 


The first half of the lower drc 1 s finished yesterday and there is one spacing violation in 
poly. There is a 16.5 micron (330 udr) gap between the gtlb and ctag's along the top edge 
of the gtlb. This needs to be filled in before the fracturing can start for the lower 
layers . 

The good news is; that's the only real drc error. 

Bummer . 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO I (tm) All kids love Log! # inc luce 

<std_disclaim.h> 
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From: 
Sent: 
To: 

Subject: 


Tom Vo [vo@merope] 

Monday, October 31, 1994 2:15 PM 

'Dave Van't Hof ; 'Lisa Robinson'; Tim B. Robinson'; 'Geert Rosseel'; 'Mark Hofmann' 
euterpe short 


I believe that the short came about because of a disconnect in the pl_eus layout vs its 
gards model . 

If we had built proteus , we would have fixed this one automatically . 

Since we did not , we had to rely on people being religous about updating the files when a 
change occur ed . From the file time stamps , it looks like the layout was touched 
shortly after the GARDS model update . 


>From unix : 

-rw-r--r-- 1 chip 8153 Oct 13 11:01 

/u/chip/proteus/gards/dcell/pl_eus . pdl 
rwxr-xr-x 1 chip 4650 Oct 14 21:27 

/u/chip/proteus/compass/layouts/pl_eus . ly 

>From cvs log in /u/chip/proteus/ compass/ layouts . 

revision 15.7 0 

date: 1994/10/14 21:50:23 LT; author: rich; state: Exp; lines: +2 -2 
Release Target: proteus/compass/layouts 

connected shield wires to vdde . 


revision 15 . 69 

date: 1994/10/14 21:16:42 LT; author: rich; state: Exp; lines: +5 -5 
Release Target: proteus/compass/layouts 

moved metal5 pads and fixed routing problem in pl_eus_sof a . ly 


What's the fix to this problem ? We need to ensure all the cells 
referenced 

by the baseplate are locked , then reissue an update-chip to proteus/dcell 
and 

proteus/gards . 


tvo 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, October 31, 1994 2:32 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory.c 


Update of /p/cvs root /gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . c 
Log Message : 

If expect a good access structure from ACCESS__PTR, but instead get a NULL, cause an 
exception rather than calling sim_err{). 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, October 31, 1994 2:35 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory, h 


Update of /p/cvsroot/gnu- tools/sim/terp 

In directory calliope : /N/auspex/root/ s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . h 
Log Message : 

Modified inline functions access_ptr() and mem_ptr() to always check that the address 
falls within the access structure's specified range. 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 31 , 1994 2:57 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/lt BOM 66.0 initiated by woody completed @ Mon Oct 31 
11:55:30 PST 1994 with exit status 0.. chip 
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From: Buffalo Chip [chip@rhea] 

Sent: Monday, October 31 , 1 994 3: 1 4 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cp BOM 18.0 initiated by dickson completed @ Mon Oct 31 
12:12:35 PST 1994 with exit status 0.. chip 
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From: vant [vanthof@hestia] 

Sent: Monday, October 31 , 1 994 3:33 PM 

To: Tom Vo' 

Cc: Vanthof@merope'; 'lisar@merope'; 'tbr@merope'; 'geert@merope'; 'hopper@merope' 

Subject: Re: euterpe short 


Tom Vo writes: 
> 

>What 1 s the fix to this problem ? We need to ensure all the cells 
referenced 

>by the baseplate are locked , then reissue an update- chip to 
proteus/dcell and 
>proteus/gards . 
> 

>tvo 


I'll verify the locked cells. At one point, they were all locked. 

Thanks , 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO ! <tm) All kids love Log! #incluce 
<std_disclaim . h> 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 
Monday, October 31, 1994 3:44 PM 
'geert@rhea' 
pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/ctiod BOM 11.0 initiated by dickson completed @ Mon Oct 31 
12:41:36 PST 1994 with exit status 0.. chip 

all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Monday, October 31, 1994 4:13 PM 
Tom Vo 1 

'Geert Rosseel'; 'Mark Hofmann'; 'Lisa Robinson'; 'Dave Van't Hof 
euterpe short 


Tom Vo wrote (on Mon Oct 31) : 


I believe that the short came about because of a disconnect in 
the pl_eus layout vs its gards model . 

If we had built proteus , we would have fixed this one automatically . 

Since we did not , we had to rely on people being religous about updating 
the files when a change occured . From the file time stamps , it looks 
like the layout was touched shortly after the GARDS model update . 


>From unix : 

-rw-r--r-- 1 chip 8153 Oct 13 11:01 

/u/ chip/proteus/gards/dcell/pl_eus .pdl 

rwxr-xr-x 1 chip 4650 Oct 14 21:27 

/u/chip/proteus/compass/layouts/pl_eus. ly 

>From cvs log in /u/chip/proteus/compass/layouts . 

revision 15.70 

date: 1994/10/14 21:50:23 LT; author: rich; state: Exp; lines: +2 -2 
Release Target: proteus /compass /layouts 

connected shield wires to vdde . 


revision 15.69 

date: 1994/10/14 21:16:42 LT; author: rich; state: Exp; lines: +5-5 
Release Target: proteus /compass /layouts 

moved metal5 pads and fixed routing problem in pl_eus_sof a . ly 


What's the fix to this problem ? We need to ensure all the cells referenced 
by the baseplate are locked , then reissue an update- chip to proteus/dcell and 
proteus/gards . 

We should be using the snapshot copy. We cannot contiue to rely on the /u/chip copy 
because changes way well be made (say to support 
Mnemosyne) that we do not want to see. 


Tim 
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From: Fred Obermeier [fwo@pelagon] 
Sent: Monday, October 31 , 1 994 4:30 PM 
To: , solo@echidna l ; 'wamp1er@thoas' 

Cc: 'al@echidna'; 'cadettes@echidna'; 'fung@echidna'; 'geert@echidna'; 'mudge@echidna'; 
'paulp@echidna'; 'tbr@pelagon' 

Subject: Re: FWD: Re-animate twinvia program? 

Solo sez: 

> as Kurt Wampler was saying 

> .. 

> ..So, to put the question: given the experience we have so far with minimum 

> ..square metal features in MOBIMOS, would it be helpful to deploy this program 

> ..as part of the standard tapeout flow? (Keep those eggs & tomatoes at less 

> ..than Mach 1, please.) 
> .. 

>..-Kurt 
> .. 

> I am a firm believer that if you can open a .5 x .5 via 99.999 % of 

> the time, that you can open one out of two 99.99999999 % of the time. 

> I think a .5 x 1.5 has as good a chance as two .5x.5 or better. 

> regards, EMail solo@microunity.com 

> solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 

Functional yield arguments aside, I'm sure that we have contacts 
where we are driving sufficiently high currents that would benefit 
in increased chip lifetime and yield to have a larger cross-section 
contacts. The overall parasitic capacitance increase due to these 
larger contacts should be minimal. 

Fred. 
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From: Tom Laidig [tom@clio] 

Sent: Monday, October 31, 1994 5:08 PM 

To: Tom Laidig' 

Cc: 'euterpe@clio'; 'cadettes@clio'; 'Paul Poenisch' 
Subject: Re: IMMINENT DECISION: atom change 

Tom Laidig writes: 

I 

J Well, we're trying to finalize the euterpe baseplate, so in keeping with 
jtradition this seems like the time to change the atom... 

I 

] Seriously, I _am_ suggesting a slight atom change, which technically 
| does not affect any baseplate layers. The change I propose is to 
(remove the SDEC 'halo' around the atom (consistent with the atom's 
[disposition, this halo is broken into 3 pieces). This SDEC geometry 
|was originally put into the atom when we planned to have the SDEC layer 
jfixed in the baseplate, and it was felt that having some straps 
javailable for jumpers would be desirable. Since we decided to allow 
ISDEC to be programmed in a 'metal change' (over a year ago), this 
jargument no longer holds, and the presence of the SDEC in all atoms 
| increases capacitance slightly and increases (again slightly) the 
| chance of SDEC shorts if some small SDEC isolation feature doesn't get 
{manufactured correctly. More importantly, it contributes to some 
| structures at the edges of sofa areas where it is difficult to 
j synthesize an effective SDEC isolation mask. 
I 

1 1 have checked all xb*, ea*, and sc* cells, and all other sofa cells 
jfor which we currently build gards models. The only cells I found that 
juse this SDEC are 
I 

| scsynchll 
I cged 
j iosynchll 
j ealnf20s6x3a 
I 

|Of these, I believe 'cged' and 'iosynchll' are obsolete ('cged' also 
jonly uses SDEC in parallel with much lower-resistance metal 
(connections). The desired SDEC can easily be drawn into 'sccynchll'; 
I'ealnf20s6x3a' uses an SDEC path to carry what looks like 1mA of 
(current, which is a bad idea anyway, and I think needs to be fixed for 
|electrical reasons. 

|I have not checked anything else that may use the eel atom, but it seems 
jclear that the use of this SDEC is quite rare. 

|So here's what I propose: 

j ril remove the SDEC from the atom, and some little plugs of SDEC 
j that appear in some hemming cells strictly to satisfy SDEC design 
I rules at the edges. 

j I'll patch 'scsynchll' and 'ealnf20s6x3a*. 

j Solo's periodic DRC/LVS runs will check up on me. 
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I I'll take the action to fix anything this might break. 


(Since this should be done quickly if it's going to be done at all, I'd 
jlike to make this decision final and do my edits on Monday Oct 3 1 . 
jObjections? 

Hearing no objections, this decision is now final. I have just released 
changes to the following layouts: 

cged.ly 
cli.ly 

ealnf20s6x3a.ly 

hemecMrs.ly 

hemgwjrs.ly 

hemifl_bs.ly 

hemiflts.ly 

hemifr_bs.ly 

hemifr_ts.ly 

ifl.ly 

ifr.ly 

iobyteO.ly 

iocvr.ly 

iomux8cel2.1y 

ioquadctrl.ly 

ioskew.ly 

iosynchlatly 

mobieclium.ly 

mobieclium_unu.ly 

scsynchll.ly 

Solo's suite of drc and Ivs tests have been run on these layouts before 
I checked them in, so we have some reason to hope that everything is OK. 
The only change to most of the above cells was to remove some bits of 
SDEC at the edges of rows of atoms - these bits used to be needed to 
make it legal, and became illegal when the matching SDEC was removed 
from the atom. 


ooooO Ooooo 

(JO 

l( Tom )| 
( ) L ( ) 
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From: Tom Laidig [tom@clio] 

Sent: Monday, October 31, 1994 5:41 PM 

To: Tom Laidig' 

Cc: 'euterpe@clio'; 'cadettes@clio'; 'Paul Poenisch' 

Subject: FINAL DECISION: atom change j 

I 

Sorry, I forgot to fix the title so it says 'FINAL DECISION", which I ! 
ought to have done to follow the proper form. Otherwise, this message 
just copies the one I sent a Iittly while ago... 


Tom Laidig writes: 

jWell, we're trying to finalize the euterpe baseplate, so in keeping with 
jtradition this seems like the time to change the atom... 

ISeriously, I _am_ suggesting a slight atom change, which technically 
[does not affect any baseplate layers. The change I propose is to 
[remove the SDEC 'halo' around the atom (consistent with the atom's 
| disposition, this halo is broken into 3 pieces). This SDEC geometry 
jwas originally put into the atom when we planned to have the SDEC layer 
j fixed in the baseplate, and it was felt that having some straps 
javailable for jumpers would be desirable. Since we decided to allow 
j SDEC to be programmed in a 'metal change 1 (over a year ago), this 
[argument no longer holds, and the presence of the SDEC in all atoms 
j increases capacitance slightly and increases (again slightly) the 
jchance of SDEC shorts if some small SDEC isolation feature doesn't get 
[manufactured correctly. More importantly, it contributes to some 

I structures at the edges of sofa areas where it is difficult to 
[synthesize an effective SDEC isolation mask. 

I I have checked all xb* 3 ea*, and sc* cells, and all other sofa cells 

jfor which we currently build gards models. The only cells I found that 
juse this SDEC are 

| scsynchll 

I cged 

j iosynchll 
j ealnf20s6x3a 

|Of these, I believe v cged' and ' iosynchll' are obsolete f cged' also 
[only uses SDEC in parallel with much lower-resistance metal 
[connections). The desired SDEC can easily be drawn into 'sccynchll'; 
jealni20s6x3a' uses an SDEC path to carry what looks like 1mA of 
Icurrent, which is a bad idea anyway, and I think needs to be fixed for 
jelectrical reasons. 

I I have not checked anything else that may use the eel atom, but it seems 
[clear that the use of this SDEC is quite rare. 

ISo here's what I propose: 

j I'll remove the SDEC from the atom, and some little plugs of SDEC 
j that appear in some hemming cells strictly to satisfy SDEC design 
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rules at the edges. 

I'll patch 'scsynchll' and "ealn£20s6x3a'. 

Solo's periodic DRC/LVS runs will check up on me. 

I'll take the action to fix anything this might break. 


jSince this should be done quickly if it's going to be done at all, I'd 
jlike to make this decision final and do my edits on Monday Oct 31. 
[Objections? 

Hearing no objections, this decision is now final. I have just released 
changes to the following layouts: 

cged.ly 
cli.ly 

ealnf20s6x3a.ly 

hemecl_Irs.ly 

hemgw lrs.ly 

hemifl bs.ly 

hemiflts.ly 

hemifr_bs.Iy 

hemifiMs.ly 

ifl.ly 

ifr.ly 

iobyteO.ly 

iocvr.ly 

iomux8cel2.1y 

ioquadctrl.ly 

ioskew.ly 

iosynchlat.ly 

mobieclium.ly 

mobieclium_unu.ly 

scsynchll.ly 

Solo's suite of drc and lvs tests have been run on these layouts before 
I checked them in, so we have some reason to hope that everything is OK. 
The only change to most of the above cells was to remove some bits of 
SDEC at the edges of rows of atoms -- these bits used to be needed to 
make it legal, and became illegal when the matching SDEC was removed 
from the atom. 


ooooO Ooooo 

(JO 
l( Tom )| 

( ) L ( ) 
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Subject: 


Sent: 
To: 

Cc: 


From: 


john mudge [mudge@hera] 
Monday, October 31, 1994 6:23 PM 
'geert@hera' 
'mudge@hera' 

Euterpe Membrane Probe Card 


Geert , 

If you are interested, they will be here at 10:00 a.m. Probably in PECR. 

j ohnnymudge 

Begin Included Message 

>From andrew@charybdis Mon Oct 31 14:43:06 1994 
Date: 31 Oct 1994 15:42:29 -0800 
From: "andrew" <andrew@charybdis> 
Subj ect : Euterpe Membrane Probe Card 

To: "Bill Herndon" <bill@gaea>, "Jeff Kaskey" < jef f@gaea>, 

"John Mudge" <mudge@gaea> / "Tim B. Robinson" <tbr@gaea> / 

"Tom Vo" <vo@gaea> 
Content -Length: 709 

Probe Technology were here last week to demonstrate their membrane probe card 

- the results looked very encouraging on our own KLA wafer prober. Very consistent, small 

(12uM across) probe marks. 

They feel that they can do one for euterpe and will be here tomorrow to 
discuss the options. Please come with your thoughts on what's required 
to 

probe euterpe - in particular, the power requirements and number of internal pads. One of 
the limitations is the amount of current we can pass through any one trace, I'd like to 
determine if this is an issue for euterpe. 

Agenda : 

Membrane overview 

Euterpe membrane, what's possible, # of internal pads? 
Current limitations, per bump & per trace 


Andrew 


End Included Message 
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Subject: 


From: 
Sent: 
To: 


andrew [andrew@charybdis] 
Monday, October 31, 1994 7:12 PM 

'Bill Herndon'; 'Geert Rosseel'; 'Jeff Kaskey'; 'John Mudge'; 'Tim B. Robinson'; 'Tom Vo'; 

'andrew@charybdis' 

RE: Euterpe Membrane Probe Card 


The membrane meeting is Tuesday 10am in PECR. 
Andrew 


From: andrew on Mon, Oct 31, 1994 3:42 PM 
Subject: Euterpe Membrane Probe Card 

To: Bill Herndon; Jeff Kaskey; John Mudge; Tim B. Robinson; Tom Vo 

Probe Technology were here last week to demonstrate their membrane probe card 

- the results looked very encouraging on our own KLA wafer prober. Very consistent, small 

(12uM across) probe marks. 

They feel that they can do one for euterpe and will be here tomorrow to 
discuss the options. Please come with your thoughts on what's required 
to 

probe euterpe - in particular, the power requirements and number of internal pads. One of 
the limitations is the amount of current we can pass through any one trace, I'd like to 
determine if this is an issue for euterpe. 

Agenda : 

Membrane overview 

Euterpe membrane, what's possible, # of internal pads? 
Current limitations, per bump & per trace 


Andrew 
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